Significant-Gravitas/AutoGPT · error · Error
Unexpected response from server
Error message
Unexpected response from server
What it means
Thrown by the NeedsAttentionList approve/decline handler when the execution-review mutation resolves with a status other than 200. Per the code comment, the generated mutation resolves (doesn't throw) on non-2xx, so this explicit guard converts silent failures into user-visible errors — otherwise the row would just reappear on refetch with no explanation.
Source
Thrown at autogpt_platform/frontend/src/components/organisms/NeedsAttentionList/useNeedsAttentionList.ts:54
[
{
node_exec_id: review.node_exec_id,
approved,
// No message: this surface has no field to write one in, and a
// canned English string would reach the agent's context and the
// audit trail as if the user had typed it.
auto_approve_future: false,
},
],
[review.graph_exec_id],
);
// The mutation resolves rather than throws on a non-200, and a 200 can
// still carry failed_count > 0 (review already processed, node
// execution gone). Reporting either as success would leave the row
// reappearing on the next refetch with nothing explaining why.
if (res.status !== 200) {
throw new Error("Unexpected response from server");
}
if (res.data.failed_count > 0) {
throw new Error(res.data.error || "The review could not be processed.");
}
toast({ title: approved ? "Approved" : "Declined" });
} catch (error) {
toast({
title: `Failed to ${verb} review`,
description:
error instanceof Error ? error.message : "An error occurred",
variant: "destructive",
});
} finally {
setPending(review.node_exec_id, false);
}
}
View on GitHub (pinned to 9c8bb5550f)
Solutions
- Check the mutation request in DevTools for the real status/body — the thrown message intentionally includes no detail, the network tab has it.
- 401 → sign in again; the pending row will still be there after re-auth.
- Refresh the list: if the row vanished, the review was already processed or the execution was pruned — nothing left to act on.
- 5xx → retry once backend health is restored; the mutation is idempotent from the UI side.
Defensive patterns
Strategy: try-catch
Type guard
function isUnexpectedServerResponse(err: unknown): boolean {
return err instanceof Error && err.message === "Unexpected response from server";
} Try / catch
try {
await reviewMutation(...);
} catch (error) {
if (isUnexpectedServerResponse(error)) {
// check network tab for the real status; refresh list before retry
await queryClient.invalidateQueries({ queryKey: ["needsAttention"] });
}
} Prevention
- Never assume generated mutations throw on non-2xx — add explicit status checks like this one.
- Invalidate the attention list after any failure so stale rows can't be re-acted on.
- Include the status code in the thrown message when extending this code — it currently forces a network-tab trip.
When it happens
Trigger: POST of the agent-review batch returning 401 (expired session), 404 (graph execution deleted), 422, or 5xx while the user clicks Approve/Decline on an attention-list row.
Common situations: Session expiry on a long-idle dashboard; the execution or its review artifacts already cleaned up by retention; backend restart between list load and action.
Related errors
- The review could not be processed.
- Failed to fetch session (status: ${response.status})
- Failed to update schedule
- n8n template not found (${res.status})
- Failed to update email
AI-assisted analysis of Significant-Gravitas/AutoGPT@9c8bb5550f (2026-08-14).
Data as JSON: /api/errors/7f76b9d9fefeada2.
Report an issue: GitHub.