Skip to content

fix: stop draft action failures from spamming Sentry as console errors#5082

Draft
cursor[bot] wants to merge 1 commit into
mainfrom
cursor/agent-10ad0e79
Draft

fix: stop draft action failures from spamming Sentry as console errors#5082
cursor[bot] wants to merge 1 commit into
mainfrom
cursor/agent-10ad0e79

Conversation

@cursor
Copy link
Copy Markdown
Contributor

@cursor cursor Bot commented May 30, 2026

Problem

Sentry issue #7516014716 reports the error publish failed: 500 {"code":13,"message":"internal error","details":[]} from https://app.superplane.com/{org}/canvases/{canvas}.

The error originates in web_src/src/components/AgentSidebar/widgets/DraftActionsWidget.tsx. When the agent sidebar's draft bar tries to Publish/Discard a draft version, it called the API with raw fetch and on any non-2xx response logged the status + body through console.error:

console.error(`${action} failed:`, response.status, text);

Our Sentry init wires up captureConsoleIntegration({ levels: ["warn", "error"] }), so every console.error is converted into a Sentry error-level event. With action === "publish" the captured message is exactly:

publish failed: 500 {"code":13,"message":"internal error","details":[]}

That is the title we see in Sentry.

Beyond the noise, the widget had two related problems:

  • It bypassed the existing React Query mutation hooks (usePublishCanvasVersion, useDeleteCanvasVersion), so successful agent-driven publishes/discards never invalidated canvas/version caches the rest of the canvas page relies on.
  • The user got no toast or visible feedback on failure — the only signal was a swallowed console message.

Fix

  • Switch DraftActionsWidget to use the existing usePublishCanvasVersion / useDeleteCanvasVersion mutations so caches are invalidated consistently and error handling matches handlePublishVersion in pages/workflowv2/index.tsx.
  • Surface failures via showErrorToast(getApiErrorMessage(...)) instead of console.error, giving the user an actionable message and keeping transient backend errors out of Sentry.
  • Add DraftActionsWidget.spec.tsx covering the four code paths: publish success/failure and discard success/failure, and asserting that failures show a toast and do not call console.error.

This is the same class of fix as #5053 / #4936, which removed Sentry noise from auto-save and browser-extension error paths.

Tests

  • npx vitest run src/components/AgentSidebar/widgets/DraftActionsWidget.spec.tsx — 4 passed.
  • make check.build.ui — clean.
  • make format.js — no changes.
Open in Web Open in Cursor 

Sentry issue #7516014716 (publish failed: 500) was triggered by the
agent sidebar's draft action widget. When a Publish/Discard request to
/api/v1/canvases/{canvas}/versions/{version}/publish came back with a
non-2xx response (e.g., a transient backend 500), the widget logged the
status and body via console.error. The Sentry React SDK is configured
with captureConsoleIntegration({ levels: ['warn', 'error'] }), so each
console.error became a server-side error event titled
'publish failed: 500 {"code":13,"message":"internal error","details":[]}'
even though the user already had nothing actionable on the page.

The widget also bypassed the React Query SDK hooks the rest of the
canvas page uses, so successful publishes/discards from the agent
sidebar didn't invalidate canvas/version caches.

Switch the widget over to the existing usePublishCanvasVersion and
useDeleteCanvasVersion mutations, surface errors via showErrorToast
with getApiErrorMessage (so the user sees a real message instead of
nothing), and stop emitting console.error so transient backend failures
no longer pollute Sentry. Add unit tests covering both success and
failure paths to lock in the new behavior.
@superplanehq-integration
Copy link
Copy Markdown

👋 Commands for maintainers:

  • /sp start - Start an ephemeral machine (takes ~30s)
  • /sp stop - Stop a running machine (auto-executed on pr close)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant