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

  1. Refetch the attention list — if the row is gone, the review was handled elsewhere and no action is needed.
  2. 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).
  3. Avoid acting on the same row from multiple tabs simultaneously.
  4. 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

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


AI-assisted analysis of Significant-Gravitas/AutoGPT@9c8bb5550f (2026-08-14). Data as JSON: /api/errors/966d313bd548b152. Report an issue: GitHub.