[eshurakov]

Summary

linkAccountToExistingUser reported every account-linking failure to Sentry via captureException, including expected user errors like ACCOUNT-ALREADY-LINKED (user tried to link a provider account already attached to another Kilo user) and PROVIDER-ALREADY-LINKED. This produced noisy Sentry issues such as GET /api/auth/callback/githubAccount linking failed: ACCOUNT-ALREADY-LINKED.

The NextAuth signIn handler in server.ts already treats these codes as expected and skips Sentry, but the capture in linkAccountToExistingUser fired unconditionally before that check. This PR guards the captureException so only LINKING-FAILED (a genuine system error — the DB insert returned nothing) is reported. Expected errors still return normally and redirect the user to the appropriate error page.

Verification

• No manual testing performed — change is a conditional guard around an existing Sentry call; oxlint passes (0 warnings, 0 errors) and existing multi-auth.test.ts coverage of linkAuthProviderToUser error codes is unaffected. Full web typecheck could not complete within the CI-agent sandbox time limit.

Visual Changes

N/A

Reviewer Notes

linkAuthProviderToUser returns exactly three failure codes (ACCOUNT-ALREADY-LINKED, PROVIDER-ALREADY-LINKED, LINKING-FAILED), so the === 'LINKING-FAILED' guard covers all unexpected cases.

[kilo-code-bot]

Code Review Summary

Status: No Issues Found | Recommendation: Merge

Executive Summary

The Sentry-noise guard around captureException in linkAccountToExistingUser is correct, type-safe, and consistent with the existing expected-error handling in the NextAuth signIn handler.

Files Reviewed (1 file)

• apps/web/src/lib/user/index.ts

Verification notes: Confirmed against current HEAD (0217c93) that linkAuthProviderToUser returns exactly the three failure codes ACCOUNT-ALREADY-LINKED, PROVIDER-ALREADY-LINKED, and LINKING-FAILED (see LinkAuthErrors type), so the === 'LINKING-FAILED' guard suppresses only expected user errors while still reporting genuine system failures. Both callers (createOrUpdateUser auto-link path and the signIn account-linking flow) propagate the returned codes to server.ts, which already treats the two expected codes as non-Sentry errors and redirects the user — behavior is preserved. Error return values, redirect flow, and existing test coverage are unaffected.

---

_{Reviewed by kimi-k3 · Input: 35.5K · Output: 4.5K · Cached: 200.7K}

_{Review guidance: REVIEW.md from base branch main}