fix: prevent startup crash for new users

[odarome132]

Closes #4

Summary

— a null pointer exception crashed the app on startup for newly registered users.

Root cause: GET /api/account read userRows[0].publicKey without first checking the row exists. A valid session cookie paired with a missing User row (registration timing, DB reset, stale cookie) dereferenced undefined, throwing a null-pointer error and crashing the dashboard at startup.

What changed

• backend/src/routes/account.ts — added a guard: if the authenticated session has no matching user row, return 401 { error: "User not found. Please sign in again." } instead of dereferencing undefined. The client already redirects to /onboarding on 401.
• frontend/src/app/page.tsx — when the account payload is missing (not logged in / backend error), the dashboard now stops loading (setLoading(false)) and renders the empty state instead of hanging on the spinner.
• backend/src/tests/account.test.ts — new test suite mirroring the repo's existing pattern (api.test.ts: Fastify + server.inject, getDb() mocked via vi.mock), covering success, failure, and edge paths.

Key design decisions

• A missing user row is treated as an authentication problem (401), not a server error (500), so the client's existing 401 → /onboarding flow handles it with no new client-side state machine.
• The DB is mocked at the module boundary (vi.mock("../lib/db")), so tests exercise the real route logic without needing DATABASE_URL — consistent with the repo's existing tests.
• The frontend fix is minimal: stop the spinner before returning; the dashboard already renders safely with empty defaults.

Acceptance-criteria checklist

• App no longer crashes on startup for new users — missing-user path returns 401 (test: "returns 401 instead of crashing when the session user has no DB row (null-pointer regression)").
• New users (no rules/transactions/limits) get a working dashboard — test asserts 200, activeRules: 0, empty transactions, plan: "free".
• Unauthenticated access still rejected — tests assert 401 on GET and PATCH without a session cookie.
• Populated users keep full data — test asserts limits, plan, rule count, and transactions are returned.
• PATCH updates still work — test asserts { success: true } when authenticated.
• Typecheck + lint pass — backend tsc --noEmit clean; frontend tsc --noEmit clean and npm run lint 0 errors.

Test output + coverage

Commands used:

cd backend && npm ci && npx vitest run --coverage
cd frontend && npm ci && npx tsc --noEmit && npm run lint

• Backend: 2 test files, 10/10 tests passed (6 new account tests + 4 existing).
• Coverage for the changed file backend/src/routes/account.ts: 100% statements, 100% lines, 100% functions, 81.25% branches — the only uncovered branches are the CASE WHEN conditionals in the pre-existing PATCH route. The repo has no configured coverage threshold; the changed lines are fully covered.
• Frontend: tsc --noEmit clean; npm run lint reports 0 errors (32 pre-existing warnings, none in changed files).

Honest follow-ups

• The PATCH route's CASE WHEN branches could get dedicated tests to push branch coverage to 100%.
• A UI-level regression test (e.g. Playwright) for the dashboard's 401 → /onboarding redirect would strengthen coverage of the frontend change.

Security note

No secrets, keys, or credentials are introduced. The change only adds a null-guard and a graceful-loading path; auth semantics (401 on missing/invalid session) are unchanged.

[drips-wave]

@odarome132 Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits

[vercel]

@odarome132 is attempting to deploy a commit to the thisisouvik's projects Team on Vercel.

A member of the Team first needs to authorize it.

[thisisouvik]

Check and give PR

[thisisouvik]

add error message for not sucessful auth