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

  1. Check the mutation request in DevTools for the real status/body — the thrown message intentionally includes no detail, the network tab has it.
  2. 401 → sign in again; the pending row will still be there after re-auth.
  3. Refresh the list: if the row vanished, the review was already processed or the execution was pruned — nothing left to act on.
  4. 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

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


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