fix: keep the WalletConnect connection timeout out of Sentry

[decentraland-bot]

Summary

• Error: Connection timeout from decentraland-connect's WalletConnectV2Connector is now classified as an unreported wallet condition: it stays out of Sentry, but still reaches the console and the LOGIN_ERROR analytics event, and the login screen still shows "Connection timeout" as the error detail.
• The match is narrow: a real Error, no code, exact message Connection timeout.

Sentry issue: https://decentraland.sentry.io/issues/7192792184/ (AUTH-SITE-HZ, unresolved since 2026-01-15, 87 events / 30 users)
Exception: Error: Connection timeout
Culprit: node_modules/decentraland-connect/dist/connectors/WalletConnectV2Connector.js → timeout (the 300 000 ms timer in openModalAndWaitForConnection), captured through handleError(error, 'Error during login connection') in LoginPage.tsx.

Root cause

#523 (merged 2026-09-22, shipped in auth@5.3.0) fixed the split wagmi/WalletConnect state that could leave a paired wallet waiting on the wrong AppKit instance. The issue kept firing on auth@5.3.0 afterwards (6 events, 2026-10-01 → 2026-10-18), so this run looked at what those events have in common. All six have the same breadcrumb shape:

1. the AppKit modal opens (ui.click body > w3m-modal.open),
2. the user clicks around inside it for a few seconds,
3. no wallet pairs, and
4. exactly five minutes later the connector's own timer rejects with Connection timeout.

That is the user leaving the QR modal open without finishing the pairing: the same kind of event as "User closed the modal without connecting", which is already kept out of Sentry. Nothing in the app failed. The login screen already handles it (connection-failed copy with the timeout as the detail).

It goes into isUnreportedWalletCondition rather than isExpectedWalletError on purpose: the latter blanks the error detail on the login screen, and "Connection timeout" is the line that tells the user what happened.

Trade-off

The same timer would also fire if a wallet paired but AppKit never reported the account (the case #523 targeted). None of the post-5.3.0 events show a pairing, but if that case comes back it would no longer surface in Sentry. It is still counted: every timeout keeps emitting LOGIN_ERROR with error: "Connection timeout", so a rise is visible in analytics.

eth-connect (a transitive dependency, not imported by src/) can also reject with Error("Connection timeout"); it is not on any path handleError sees today.

Changes

• src/shared/errors.ts: one more case in isUnreportedWalletCondition, docs updated.
• src/shared/errors.spec.ts: matches the bare timeout; does not match a plain object, an error with a code, or a different message; stays out of isExpectedWalletError.
• src/shared/utils/errorHandler.spec.ts: the timeout is not sent to Sentry and is still tracked.

Testing

• npx jest: 74 suites, 1926 tests passed
• npx eslint on the touched files: clean
• npx tsc --noEmit: clean
• npm run build: passes

Tracking

No GitHub issue: the Sentry issue above is the tracker for this fix.

---

Opened by the weekly sentrysweep run (scheduled; schedule owner <@U026ADH14BU>). Draft: needs human review and approval.

🤖 Generated with Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
auth	Ready	Preview	Oct 18, 2026 6:18am UTC

[decentraland-bot]

sentrysweep review (advisory)

Verdict: no P0/P1. Approvable pending human approval. The bot opened this PR, so this is a comment, not an approval.

Review covered: the full pr-review checklist (bugs, error handling, unused imports, tests, API contract, security, performance, git conventions), plus TypeScript/pattern, security/architecture and simplicity review passes.

Consumer impact: none. The change is internal to the auth site's error classification (src/shared/errors.ts). It changes no route, published export or event schema.

Security: nothing to report. Only Sentry reporting changes. The error is still logged, still tracked as LOGIN_ERROR, and still shown on the login screen.

Architecture: isUnreportedWalletCondition is the right place for this, not isExpectedWalletError. LoginPage uses isExpectedWalletError to blank the error detail, and "Connection timeout" needs to stay visible.

Of the 32 handleError call sites, only LoginPage.tsx and AutoLoginRedirect.tsx can see the connector's timeout, and both are the same user situation. The app's own timeouts use different messages. eth-connect uses the same text but is not used with a network provider in src/.

Fixed during review

• Updated the comments in errorHandler.ts and the predicate's summary so they also mention the connector timeout (42d46b5).

P2 suggestions (non-blocking)

1. src/shared/errors.ts: the match depends on the exact library string. If decentraland-connect ever rewords it, the error starts reporting again, which fails safe. Consider a comment pinning the version.
2. src/shared/errors.ts: the guard is stricter than its neighbour, which matches the "User closed the modal" message only. Keep the instanceof Error / no-code guards and their tests, or simplify to the message-only convention. The reviewers disagreed, so this is the maintainers' call.
3. Trade-off the PR body already states: a wallet that pairs but is never reported back (the fix: clear wagmi connection state together with the walletconnect session #523 scenario) would now stop reaching Sentry. To keep a signal, consider a warning-level message tagged phase: connecting instead of dropping it completely.
4. LoginPage.tsx:289: the "Everything else is reported" comment was already loose before this PR. Optionally reword it.

Merge gates

• CI: test, audit and lint-package-json were pending when this comment was posted.
• Needs a human review and approval. The PR stays a draft until a maintainer marks it ready.

Sentry: https://decentraland.sentry.io/issues/7192792184/

---

Reviewed by Jarvis 🤖 · Requested by the weekly sentrysweep schedule (<@U026ADH14BU>) via Slack