Problem
Callers hanging up mid-request — tabs navigating away during auth round-trips, agent runs canceled mid tool-call, probes hitting 404 paths — are expected client behavior. But the self-hosted convex-backend records each abort as an error-level event in the app's GlitchTip project: ~1–2/day of steady noise that buries real HTTP-action failures.
Evidence (GlitchTip, demo.tale.dev)
- TALE-PROJECT-OD —
Error: Client disconnected, error level, 75 events 2026-07-06 → 2026-08-27T10:58Z (still accruing). Sampled events spread across ordinary HTTP actions — GET /api/auth/get-session (majority), POST /api/tools/execute, GET /api/auth/convex/token, GET /api/config, POST /api/auth/organization/set-active, even GET /api/v2/static/not.found — all server_name: tale_platform, backend-generated.
Nothing here indicates a server defect; only the POST /api/tools/execute aborts deserve one look (long tool executions vs caller timeout policy) before the group is written off entirely.
Proposed direction
- Treat client aborts as non-errors: downgrade/skip "Client disconnected" in our
tale-convex image's error reporter (same upstream-touch territory as the Postgres stop-ordering work), or failing that a GlitchTip filter / grouping+mute rule for the message.
- While in there, sanity-check
/api/tools/execute (services/platform/convex/http.ts:988) latency against its callers' timeout/abort behavior — sandbox agents canceling tool calls is expected, a systematic client-side timeout would not be.
Acceptance
Client aborts no longer create error-level GlitchTip events (or land in one muted group), while real HTTP-action failures stay visible.
Filed by the GlitchTip triage sweep of demo.tale.dev (2026-08-28). Tracked on the tale board as TAL-19 — "convex-backend error-reports every client abort: 'Client disconnected' noise across HTTP actions" (status: backlog).
Problem
Callers hanging up mid-request — tabs navigating away during auth round-trips, agent runs canceled mid tool-call, probes hitting 404 paths — are expected client behavior. But the self-hosted convex-backend records each abort as an error-level event in the app's GlitchTip project: ~1–2/day of steady noise that buries real HTTP-action failures.
Evidence (GlitchTip, demo.tale.dev)
Error: Client disconnected, error level, 75 events 2026-07-06 → 2026-08-27T10:58Z (still accruing). Sampled events spread across ordinary HTTP actions —GET /api/auth/get-session(majority),POST /api/tools/execute,GET /api/auth/convex/token,GET /api/config,POST /api/auth/organization/set-active, evenGET /api/v2/static/not.found— allserver_name: tale_platform, backend-generated.Nothing here indicates a server defect; only the
POST /api/tools/executeaborts deserve one look (long tool executions vs caller timeout policy) before the group is written off entirely.Proposed direction
tale-conveximage's error reporter (same upstream-touch territory as the Postgres stop-ordering work), or failing that a GlitchTip filter / grouping+mute rule for the message./api/tools/execute(services/platform/convex/http.ts:988) latency against its callers' timeout/abort behavior — sandbox agents canceling tool calls is expected, a systematic client-side timeout would not be.Acceptance
Client aborts no longer create error-level GlitchTip events (or land in one muted group), while real HTTP-action failures stay visible.
Filed by the GlitchTip triage sweep of demo.tale.dev (2026-08-28). Tracked on the tale board as TAL-19 — "convex-backend error-reports every client abort: 'Client disconnected' noise across HTTP actions" (status: backlog).