Stop spamming Sentry on handled Splitwise 404/403

[danthareja]

Production was firing handled SplitwiseNotFoundError (and SplitwiseForbiddenError) into Sentry every time a user submitted a stale Splitwise group ID on POST /dashboard/setup. The dashboard already converted both into a clean { hasAccess: false } response, so these were noise events with no user impact.

The splitwise-axios interceptor wraps all 4xx responses into typed SplitwiseError subclasses before rejecting. The catch block in getSplitwiseGroup still tested error instanceof AxiosError && error.response?.status === 404, so the early-return branches have been dead code since the interceptor was introduced in 9e1fbb9. Falling through hit Sentry.captureException and returned the generic SplitwiseError message in place of the original "Group not found" / "No access to group". Matching on the typed subclasses fixes both the noise and the regressed error strings. The unexpected-error path (5xx, network, malformed responses) still reports to Sentry.

Adds tests/services/splitwise-auth.test.ts covering the four exit paths (200, 403, 404, 500) and asserting Sentry.captureException is not called for the expected 404 and 403 cases.

Sentry issue: 7442059847.

---

[vercel]

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

Project	Deployment	Actions	Updated (UTC)
splitwise-for-ynab	Error		Apr 27, 2026 3:31pm

[maxwellgordon]

Tests do not have 100% coverage. Please increase coverage to 100% before approval.