POST /api/errors acknowledges reports without persisting them: error storage and forwarding are commented out

[nanaf6203-bit]

POST /api/errors acknowledges reports without persisting them: error storage and forwarding are commented out

Labels / Complexity: bug · Medium Complexity — Medium

Problem

src/app/api/errors/route.ts accepts client error reports, validates them, logs them server-side, and returns { success: true } — but the actual persistence and forwarding are commented out:

// Store in database (placeholder for actual implementation)
// await db.errors.create({ ...body });

// Send to external service (placeholder for actual implementation)
// await analyticsService.trackError(body);

Every client-side error report (sent by the error-reporting flow in src/utils/errorReporting.ts) is acknowledged as successfully stored and then dropped — the only record is the server log line. An operator relying on the error-reporting pipeline (dashboards, alerting, session replay) sees "error reported successfully" for errors that were never stored or forwarded anywhere, so production error visibility is silently absent.

Root cause

src/app/api/errors/route.ts: the storage and analytics-API calls are commented out with "placeholder for actual implementation", while the route still returns success.

Why this is architecturally hard

1. The destination must be chosen. The backend has an error-reporting surface? (check PropChain-BackEnd for an error/telemetry endpoint) or a third-party analytics service; the contributor must pick the destination, define the payload contract, and handle failures (should a failed store return 500 or still succeed?). The ErrorReportingData type in src/types/errors.ts is the starting contract.
2. The success semantics must be honest. Acknowledging a report that was dropped is the bug; the route must either persist (and fail loudly when it cannot) or return an explicit "accepted for logging only" response.

Acceptance criteria

• POST /api/errors persists or forwards each report to a real destination (backend endpoint or analytics service), with failures surfaced (non-2xx or logged distinctly).
• The placeholder for actual implementation comments are gone.
• A test covers: valid report persisted/forwarded, invalid report rejected (existing validation), and destination failure handled.
• npm run typecheck, npm test, and npm run lint pass.

Out of scope

Building a full error-dashboard product is out of scope; this is about making the endpoint do what it claims.

Getting started

• src/app/api/errors/route.ts — the commented-out persistence
• src/types/errors.ts — the payload contract
• src/utils/errorReporting.ts — the client that sends reports

Commands: npm run typecheck, npm test, npm run lint.

Good first files to read: src/app/api/errors/route.ts, src/utils/errorReporting.ts.