Skip to content

Half the API routes bypass logEvent and log unstructured strings #40

Description

@royalpinto007

Problem

The project has a structured logging helper, logEvent in lib/observability/events.ts, that emits a single JSON line with an event name and a level. It is used in only four places:

  • app/api/posts/route.ts
  • app/api/posts/[id]/vote/route.ts
  • app/api/teams/waitlist/route.ts
  • app/api/upload/presign/route.ts

Everything else logs with bare console.error and an ad hoc prefix string, including app/api/admin/posts/route.ts ([admin/posts] fetch error:), app/api/admin/posts/[id]/route.ts, app/api/newsletter/route.ts, app/api/newsletter/send/route.ts, app/api/posts/edit/[token]/route.ts, and app/api/upload/presign/route.ts (which does both, on the same error path).

Why it matters

Half the API surface is unqueryable in the Cloudflare logs. You cannot count "how many admin fetches failed today" or alert on it, because those lines are prose rather than JSON. It also means error objects are passed straight to console.error, which can serialize Supabase error payloads containing request context.

Suggested approach

  1. Extend logEvent slightly: add an ISO ts, and a requestId field pulled from the incoming request where available.
  2. Replace every console.error in app/api/** with a logEvent({ event: "<area>.<what_failed>", level: "error", ... }) call using a consistent <area>.<verb> naming convention. Document the convention in a short section of CONTRIBUTING.md.
  3. Never pass raw error objects. Pass err instanceof Error ? err.message : "unknown" like app/api/upload/presign/route.ts already does.
  4. Remove the now duplicated console.error in the presign catch block.

Done when

  • grep -rn "console.error" app/api returns nothing.
  • Event names follow one documented convention.
  • A short test asserts logEvent output parses as JSON and contains event, level, and ts.

If you want to take this on, comment on the issue to claim it and it will be assigned. Please keep to a maximum of 2 open claims per person at a time so other contributors get a chance.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or requesthelp wantedExtra attention is needed

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions