Significant-Gravitas/AutoGPT · warning · Error
The review could not be processed.
Error message
The review could not be processed.
What it means
Thrown by the same NeedsAttentionList handler when the mutation DID return 200 but res.data.failed_count > 0 — meaning the backend accepted the request yet failed to apply the review to at least one node execution (e.g. the node execution was already processed or deleted). The thrown message is res.data.error from the backend, falling back to 'The review could not be processed.' only when the backend supplied no error string.
Source
Thrown at autogpt_platform/frontend/src/components/organisms/NeedsAttentionList/useNeedsAttentionList.ts:57
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);
}
}
function approve(review: PendingHumanReviewModel) {
return decide(review, true);
}View on GitHub (pinned to 9c8bb5550f)
Solutions
- Refetch the attention list — if the row is gone, the review was handled elsewhere and no action is needed.
- If the row persists, check backend logs for why the review application failed for that node_exec_id (the 200-with-failed_count path logs the reason server-side).
- Avoid acting on the same row from multiple tabs simultaneously.
- Backend improvement: always populate the error field when failed_count > 0 so users never see the generic fallback.
Defensive patterns
Strategy: try-catch
Type guard
function isReviewProcessingFailure(err: unknown): boolean {
return err instanceof Error &&
(err.message === "The review could not be processed." || /review/i.test(err.message));
} Try / catch
try {
await reviewMutation(...);
} catch (error) {
// 200 + failed_count>0: the row may already be handled — refetch and move on
await queryClient.invalidateQueries({ queryKey: ["needsAttention"] });
toast({ description: (error as Error).message, variant: "destructive" });
} Prevention
- Treat failed_count > 0 on a 200 as a partial failure — always refetch the list afterward.
- Prevent double-submission of the same review (disable the row while pending, as setPending does).
- Push the backend to always return an error string with failed_count so the generic fallback never appears.
When it happens
Trigger: POST /graph executions/{id}/reviews returning 200 with {failed_count: 1, error: null|undefined} — node_exec_id no longer exists, review already applied by another tab/user, or a race where the execution was re-run while the review was submitted.
Common situations: Two tabs open on the same dashboard and both act on the same row; executor re-ran the node so the old node execution is superseded; retention job deleted the node execution between list fetch and click.
Related errors
- Unexpected response from server
- Authentication failed — please sign in again.
- Failed to fetch session (status: ${response.status})
- Invalid form
- Failed to update schedule
AI-assisted analysis of Significant-Gravitas/AutoGPT@9c8bb5550f (2026-08-14).
Data as JSON: /api/errors/966d313bd548b152.
Report an issue: GitHub.