Prompt

# Audit this service You are working inside a small Bun and TypeScript HTTP service. Audit the codebase for security, correctness, performance, reliability, and error-handling problems, then write your findings to `AUDIT.md` in this directory. ## What to produce For every problem you find, include in `AUDIT.md`: - The file and line number (or line range) where it occurs. - A short summary of the problem. - Its severity (critical, high, medium, or low) and why you rated it that way. - The fix you recommend, specific enough that another engineer could implement it without further investigation. After listing the individual findings, add a remediation plan that sequences the fixes: say which should be fixed first and why, call out any fix that depends on another, and flag anything that needs a production migration or a coordinated rollout rather than a plain code change. ## Constraints - Do not modify any file except `AUDIT.md`. This is a read-only audit; do not fix the issues you find. - Only report problems you can point to in this codebase. Do not pad the report with speculative or generic advice that isn't tied to a specific location in the code. - Read every file in the service before concluding your audit; do not stop at the first file that looks suspicious. Work only within this fixture directory.

Fixture

21 paths under fixture/, copied into a fresh run dir for every attempt.

.gitignore

package.json

README.md

src/

src/config.ts

src/db.ts

src/jobs/

src/jobs/dispatcher.ts

src/jobs/retry.ts

src/lib/

src/lib/crypto.ts

src/lib/http.ts

src/middleware/

src/middleware/auth.ts

src/routes/

src/routes/deliveries.ts

src/routes/events.ts

src/routes/webhooks.ts

src/server.ts

src/types.ts

tsconfig.json

README.md

# Webhook Relay

A small internal service that accepts events from other internal systems and delivers
them, over HTTP, to the webhook endpoints each account has registered. Think of it as a
lightweight version of what Stripe or GitHub run to fan a single event out to every
subscriber: an event comes in once, and this service takes care of signing it, retrying
failed deliveries, and tracking delivery status per webhook.

## Concepts

- **Account** — a tenant, identified by an API key sent as `X-Api-Key`.
- **Webhook** — a URL an account has registered to receive events, plus a per-webhook
  signing secret used to HMAC-sign every delivery (`X-Relay-Signature` header).
- **Event** — a typed payload ingested via `POST /events`. Ingesting an event creates one
  delivery per active webhook on the account.
- **Delivery** — one attempt (and its retries) to deliver a single event to a single
  webhook. Deliveries move through `pending -> sending -> delivered` or `failed`.

## API

- `POST /events` — ingest a new event (`{ type, payload }`) and fan it out to the
  account's active webhooks.
- `GET /events?type=&page=` — list ingested events, optionally filtered by type.
- `POST /webhooks` — register a new webhook (`{ url, description? }`).
- `GET /webhooks?page=` — list the account's registered webhooks.
- `GET /webhooks/:id` — fetch a single webhook.
- `DELETE /webhooks/:id` — deactivate a webhook; it stops receiving new deliveries.
- `GET /deliveries?page=` — list delivery attempts across the account's webhooks.
- `GET /deliveries/stats/today` — delivery counts by status for the current day.
- `POST /internal/dispatch-now` — operator-only route to trigger an immediate dispatch
  sweep, guarded by a shared `X-Internal-Token` header.

## Background jobs

Two sweeps run on an interval (`server.ts`):

- **Dispatcher** — sends every `pending` delivery.
- **Retry** — re-sends deliveries that didn't complete on the first attempt, with a
  backoff window before each retry, up to `MAX_DELIVERY_ATTEMPTS`.

## Running locally

Accounts and their API keys are provisioned out of band (there is no signup route in
this service); this repo assumes a row already exists in the `accounts` table.

```
bun install
bun run src/server.ts
```

Data is stored in a local `bun:sqlite` database file (`DB_PATH`, defaults to
`relay.db`).

How it is scored

Objective layer

10 planted issues to find, judged for recall with a penalty for unsupported findings.

Subjective layer · weights

Actionability (40)
Sequencing and risk coverage (30)
Precision (30)

Rubric: Codebase audit report

Score each dimension 0 to 4, based on AUDIT.md.

Actionability (weight 40)

0: Findings are vague ("improve error handling") with no file, line, or concrete fix.
1: Findings name a file but the recommended fix is generic advice rather than a specific change.
2: Most findings name a file, line, and a fix, but some fixes are too vague for an engineer to implement without re-investigating the issue.
3: Every finding names a file and line, states the problem clearly, and gives a fix specific enough to implement directly.
4: All of the above, plus fixes that account for the surrounding code (naming the actual function or variable to change, and noting any caller that would need to change too).

Sequencing and risk coverage (weight 30)

0: No remediation plan, or findings are listed with no stated order.
1: A plan exists but is just the findings list re-ordered by severity label with no reasoning.
2: The plan orders fixes sensibly and gives some reasoning, but misses a real dependency between two findings (fixing one changes how the other should be fixed) or ignores rollout risk entirely.
3: The plan correctly sequences dependent fixes, gives a reason for the ordering, and flags which fixes are safe as a plain code change versus which need a migration or coordinated rollout.
4: All of the above, plus a plan that groups fixes into batches that could ship as separate, independently verifiable changes rather than one large patch.

Precision (weight 30)

0: The report includes findings that do not correspond to anything in the actual code (hallucinated issues), or misidentifies severity in a way that would misdirect a team.
1: Mostly accurate, but at least one finding is materially wrong about what the code does.
2: All findings are accurate, but severity ratings are inconsistent (e.g., a planted security issue rated the same as a minor style nit).
3: All findings are accurate with reasonable, consistent severity ratings, and the report does not pad itself with speculative issues beyond what the code supports.
4: All of the above, plus every stated severity is justified by a concrete consequence (data exposure, incorrect results, an outage path) rather than a bare label.

Agent	Objective	Subjective	Combined	Run
grok · grok-4.6	—	—	—	#1
claude · haiku · low	75.0 (75.0–75.0, n=1)	85.0 (85.0–85.0, n=1)	79.0 (79.0–79.0, n=1)	#1
codex · gpt-5.6-sol · low	65.0 (65.0–65.0, n=1)	100.0 (100.0–100.0, n=1)	79.0 (79.0–79.0, n=1)	#1

Agent

Objective

Subjective

Combined

Run

grok · grok-4.6

—

claude · haiku · low

75.0 (75.0–75.0, n=1)

85.0 (85.0–85.0, n=1)

79.0 (79.0–79.0, n=1)

codex · gpt-5.6-sol · low

65.0 (65.0–65.0, n=1)

100.0 (100.0–100.0, n=1)