@sohambasu963draftchecks…fix/oauth-trigger-error-diagnostics → master2 files · +27 −4updated 8h agoTwo error sites generate a steady stream of support tickets because the actionable detail is hidden:
Failed to fetch OAuth2 access token: Request failed with status code 500 — the provider's actual error/error_description is logged encrypted server-side and effectively unreadable (decrypt needs the prod Doppler key). Example: LinkedIn custom-scope ticket — Datadog shows 10 LinkedIn exchange failures in the last 3 days, undiagnosable from the customer-facing string.client_id the lookup used (resolved from the connected account's auth config) — and a client_id mismatch is the dominant cause. Notion ticket: customer registered + verified an endpoint, still 404s, and can't see why.oauthInterface.ts: append the provider's RFC 6749 §5.2 error: error_description (string-typed only, capped at 300 chars) as (provider says: …). These fields are spec-defined diagnostics, never secrets; the full body remains encrypted-logged as before.resolve_v2_webhook_endpoint.ts: include the searched client_id (public OAuth identifier) + a cross-check command in the 1203 message/suggested_fix.Provider error_description is attacker… well, provider-controlled text reflected to the connecting user. It's standard practice to show it (Google/Stripe/Auth0 all do), it's length-capped, and it only renders on the OAuth failure redirect for the user who initiated the flow. Flagging anyway.
Message-string changes only; no control-flow change. Not run locally (fresh worktree) — relying on CI typecheck.
🤖 Generated with Claude Code