Waitpoint API 404s restored and log noise reduced
A catch-all handler was swallowing intentional 404s and spamming logs. Waitpoint API errors are now accurately reported, and benign queue races are downgraded to warnings.
A generic error handler was catching intentional 404 responses for stale waitpoints, stripping their details, and returning 500 codes to clients. This created thousands of false alarms per hour in production logs.
The system now correctly propagates intentional HTTP response codes back to clients without flagging them as system failures. Additionally, a benign race condition in the task queue is now treated as a warning rather than a critical error.
Sentry alerts become meaningful again, clients receive accurate waitpoint API status codes, and developers can actually see the stack traces when real errors occur.
View Original GitHub Description
Two changes to cut error volume from logs that represent handled conditions, not real errors (combined ~1600/hr in prod):
- api.v1.waitpoints.tokens.$waitpointFriendlyId.complete.ts
The route throws json(..., { status: 404 }) when a waitpoint
isn't found, but the generic catch block caught that Response,
logged it as an error (with an empty {} body because Error fields
are non-enumerable), and rethrew as a 500 — so clients saw a 500
instead of the intended 404, and every stale-waitpoint request
produced a Sentry event.
Fix: re-throw Response objects unchanged so the correct status propagates and we don't log user 404s as errors. Also serialize remaining Error instances explicitly (name/message/stack) so the logs are actionable when we do hit a real error.
- v3/marqs/sharedQueueConsumer.server.ts:603
"Task run has invalid status for execution. Going to ack" — the message itself says we're handling it gracefully. Benign race between dequeue and completion/cancellation. Demote to warn.