OpenFn / OpenFn/apollo

Send swallowed auth/migration DB errors to Sentry, and stop reporting routine 4xx

Open
#554 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

bug monitoring platform
Dominant language
Jupyter Notebook
Stars
5
Forks
10
Avg merge
2d 20h
Merged PRs (30d)
17

Description

Two related problems with how we report errors to Sentry.

First, three database failures in the client-auth path get logged with console.error and then forgotten. They never reach Sentry, so we're blind to them in production.

Second, the Elysia onError hook sends every error to Sentry, including routine 4xx like favicon bots hitting NOT_FOUND. That noise buries the errors we actually care about.

They sit in overlapping code, so it's easier to fix them together.

1. Capture the three swallowed DB errors. Each one currently console.errors and moves on:

  • platform/src/server.ts:48 — migration run failure (runMigrations()).
  • platform/src/auth/instance-auth.ts:139 — startup DB-probe (reachability) failure; auth degrades to the shape-checked forward path.
  • platform/src/auth/instance-auth.ts:275 — runtime client-lookup failure; request fails closed.

Each of these needs an explicit captureException(err, …) next to the log it already writes. captureException is already imported in instance-auth.ts:7 and used elsewhere in that file (lines 158, 251, 312), so those two sites are just inconsistent with the rest of it. server.ts needs the import adding (import { captureException } from "./util/sentry").

2. Skip 4xx in the onError hook. Request errors only reach Sentry through the onError hook at platform/src/server.ts:30-32, and it calls captureException(error) for everything. Add a status check so we only capture 5xx and unexpected errors, and skip the routine 4xx like NOT_FOUND. Elysia hands us the error code and status on the onError context, so the guard lives right there in the hook.

Sentry is wired in platform/src/util/sentry.ts (captureException is a no-op when SENTRY_DSN is unset) and initialised from platform/src/index.ts:4.

Acceptance criteria
  • Migration failure at platform/src/server.ts:48 calls captureException, with the import added to server.ts.
  • Startup DB-probe failure at platform/src/auth/instance-auth.ts:139 calls captureException.
  • Runtime client-lookup failure at platform/src/auth/instance-auth.ts:275 calls captureException.
  • The onError hook (platform/src/server.ts:30-32) only captures 5xx/unexpected errors; 4xx (e.g. NOT_FOUND) is skipped.
  • No behaviour change to the HTTP responses themselves — onError still returns nothing so Elysia produces its normal error body/status.
  • Existing log lines retained; Sentry capture is additive.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the onError hook in platform/src/server.ts:30-32, then inspect the swallowed failures at server.ts:48 and instance-auth.ts:139 and :275. Read the existing captureException uses in instance-auth.ts and the implementation in platform/src/util/sentry.ts. Done means all three DB errors are captured, routine 4xx errors are skipped, existing logs and HTTP responses remain unchanged.

Written by the indexing model from the issue text.

Assessment

Tech stack
typescript
Domain
backend, observability-sre
Issue type
Bug
Difficulty
3/5
Estimated time
1-2 days
Activity status
Quiet
Clarity
Clearly specified
Newbie friendliness
72/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.