codex · gpt-5.6-sol · low · planning-audit/planted-defects · attempt 1
v2026.09-smoke__planning-audit--planted-defects__codex--gpt-5.6-sol--low__1
okSep 6, 2026, 09:29 AM → Sep 6, 2026, 09:32 AM on unknown-host · suite v2026.09
Command
codex exec --json -m gpt-5.6-sol -c model_reasoning_effort=low -s workspace-write --dangerously-bypass-approvals-and-sandbox -C /Users/decod3rslabs/www/shipshitdev/public/benchmark/.runs/v2026.09-smoke__planning-audit--planted-defects__codex--gpt-5.6-sol--low__1/workspace --skip-git-repo-check -o /Users/decod3rslabs/www/shipshitdev/public/benchmark/.runs/v2026.09-smoke__planning-audit--planted-defects__codex--gpt-5.6-sol--low__1/workspace/../codex-last-message.md # 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.
codex codex-cli 0.153.4 · permission mode workspace-write+bypass-approvals-and-sandbox · max 40 turns · $8 budget · 25m timebox
Tokens in
192.4K
Tokens out
5.7K
Cache read
161.2K
Cache write
—
Turns
1
Tool calls
5
Wall time
2m 15s
API-equiv. cost
$0.95
Gates
This task has no deterministic gates.
Judgments
claude · haiku · label A · 100.0
actionability: 4/4sequencing-and-risk: 4/4precision: 4/4Actionability (4/4): All 17 findings cite specific file paths and line ranges. Each problem is stated clearly with concrete causes (e.g., type interpolated into SQL, markFailed missing increment, dispatchPendingDeliveries unhandled). Fixes are implementation-ready, naming actual functions (safeCompare, HttpError), variables (type, attemptCount, next_attempt_at), and required changes to callers and schemas. Sequencing and risk (4/4): The remediation plan orders findings into 7 logical phases with explicit reasoning (e.g., "Immediately block data and network boundary attacks"), correctly identifies dependencies (concurrency depends on atomic claims, both transaction/idempotency fixes need migrations), and flags deployment risk (schema first, backward-compatible migration, avoid mixed versions, rehearse against prod data). Fixes are grouped into independently shippable batches. Precision (4/4): Findings correspond to real code patterns verifiable in the stated scope (SQL in events.ts line 24, pagination offset math, token comparison, etc.). Severity ratings are internally consistent and each is justified by concrete consequences: SQL injection labeled critical with "confidentiality boundary violation," concurrent sends as high with "duplicate downstream side effects," pagination as medium with "produce a 500," N+1 as low with "adds avoidable SQLite work." No hallucinated or materially inaccurate issues; no padding beyond what the code supports.
Report
# Webhook Relay Audit Scope: every tracked file in this fixture was read. The findings below are limited to concrete behavior in the current implementation. ## Findings ### 1. Event filtering is SQL-injectable and breaks tenant isolation - **Location:** `src/routes/events.ts:15-30`, especially line 24 - **Severity:** **critical** — an authenticated tenant controls `type`, which is interpolated into SQL. Crafted input can alter the query and disclose another tenant's event payloads (and potentially other database data via `UNION`). This is a direct confidentiality boundary violation. - **Recommended fix:** Keep the SQL text static and bind `type` as a parameter (`... AND type = ?`, then append `type` to `params`). Prefer moving this query into `db.ts` so all database access follows the existing parameterized-query pattern. Add tests with quotes, SQL operators, and `UNION` payloads that prove results remain scoped to `account.id`. ### 2. Webhook URLs permit server-side request forgery - **Location:** `src/routes/webhooks.ts:44-57`; outbound use at `src/jobs/dispatcher.ts:30-38` - **Severity:** **high** — any authenticated account can register an arbitrary absolute URL, after which the service performs a POST from its trusted network. This permits blind access to loopback, private/link-local networks, and cloud metadata or internal HTTP services, including side-effecting requests. - **Recommended fix:** At registration and again immediately before dispatch, require `https:` (or an explicitly documented protocol allowlist), reject credentials and nonstandard ports unless required, resolve the hostname, and reject every resolved loopback, private, link-local, multicast, and reserved address for both IPv4 and IPv6. Pin or revalidate the resolved address when connecting so DNS rebinding cannot bypass the check, and apply the same validation to every redirect or disable redirects. If private destinations are a required feature, implement an explicit per-destination allowlist rather than accepting arbitrary URLs. ### 3. In-flight and pending deliveries can be sent more than once concurrently - **Location:** `src/db.ts:206-215,266-283`; `src/jobs/dispatcher.ts:5-9,26-38`; `src/jobs/retry.ts:5-11`; `src/server.ts:17-23,61-64`; `src/routes/events.ts:52-58` - **Severity:** **high** — selecting work and changing it to `sending` are separate operations with no conditional claim. Timer sweeps, the internal route, and event-ingestion nudges can overlap and select the same `pending` row. In addition, every `sending` row has `next_attempt_at IS NULL`, so the retry sweep treats a currently executing request as immediately retryable. Duplicate POSTs can therefore run concurrently and cause duplicate downstream side effects. - **Recommended fix:** Replace `listPendingDeliveries` plus unconditional `markSending` with an atomic claim/lease operation in a transaction: select eligible IDs, conditionally update only rows still eligible to `sending`, set a unique lease owner and lease expiry, and return only rows successfully claimed. Retry only expired leases, never all `sending` rows. Make completion updates conditional on the lease owner so a stale worker cannot overwrite a newer attempt. Also prevent overlapping sweeps in-process (a mutex or self-scheduling loop), while retaining database-level claims for multi-process safety. ### 4. API-key rotation or account revocation does not take effect in a running process - **Location:** `src/middleware/auth.ts:6-29` - **Severity:** **high** — successful credentials and their account records are cached forever. After an API key is rotated, deleted, or its account is disabled in the database, the old key remains authorized until every service process restarts. - **Recommended fix:** Do not cache credential validation, or use a bounded cache with a short TTL plus explicit invalidation integrated into the key-rotation/revocation path. Cache only the minimum account identity, cap entries, and verify revocation semantics with a test that authenticates, rotates/deletes the key, and confirms the old key is rejected without restarting the process. ### 5. Event creation and fan-out are not atomic - **Location:** `src/db.ts:181-204`; orchestration at `src/routes/events.ts:45-50` - **Severity:** **high** — the event insert commits before delivery rows are created, and delivery inserts are individually committed. A database error or process exit can leave an event with no deliveries or only a partial fan-out, with no code that reconciles the missing rows. Accepted events can be silently lost for some subscribers. - **Recommended fix:** Add a single database function that starts a SQLite transaction, inserts the event, snapshots the active webhook IDs, inserts all corresponding deliveries, and commits only after all inserts succeed. Roll back the entire operation on error. Add a uniqueness constraint on `(event_id, webhook_id)` so reconciliation or retries cannot create duplicate delivery rows; introducing that constraint requires checking and deduplicating existing rows first in production. ### 6. Missing webhook/event rows and deactivated webhooks retry forever - **Location:** `src/jobs/dispatcher.ts:18-23`; `src/db.ts:224-235,272-283` - **Severity:** **medium** — this failure branch calls `markFailed` without incrementing `attemptCount`. Such rows always satisfy `attempt_count < maxAttempts`, so the retry job reschedules them indefinitely. Deactivating a webhook with queued deliveries creates permanent retry/database load. - **Recommended fix:** Model non-retryable outcomes explicitly (for example `cancelled` or terminal `failed`) and clear `next_attempt_at` for missing/deactivated dependencies. Exclude terminal rows from retry selection. If a schema status constraint is added, deploy the schema change before code writes the new status and backfill existing affected rows as a coordinated migration. ### 7. Event ingestion has no idempotency mechanism - **Location:** `src/routes/events.ts:34-60`; schema at `src/db.ts:77-95` - **Severity:** **medium** — a client that times out after the insert and retries creates a second event and a second full set of deliveries. Network retries are normal, so downstream webhook consumers can receive duplicates even without a worker crash. - **Recommended fix:** Require or support an idempotency key on `POST /events`, persist it with the account and request fingerprint, and enforce a unique `(account_id, idempotency_key)` constraint. In one transaction, return the original result for an identical replay and reject reuse with a different body. This needs a production schema migration deployed before enabling the new write path; clients need a coordinated rollout if the header becomes mandatory. ### 8. Dispatch is serial and can fall permanently behind - **Location:** `src/jobs/dispatcher.ts:5-9`; `src/jobs/retry.ts:9-11`; timeout at `src/config.ts:15` - **Severity:** **medium** — each batch awaits up to 50 deliveries sequentially. At the default eight-second timeout, one batch can take roughly 400 seconds while new work arrives every five seconds. This creates unbounded delivery latency and also makes overlapping sweeps much more likely. - **Recommended fix:** After implementing the atomic claim/lease in finding 3, process claimed deliveries with bounded concurrency (for example a worker pool of 5-10, configurable based on capacity) using per-request timeouts. Measure queue depth and oldest-pending age, and tune batch/concurrency limits from those metrics. Do not add parallelism before atomic claiming, because that would amplify duplicate sends. ### 9. Unbounded request bodies can exhaust memory and grow the database without limit - **Location:** `src/routes/events.ts:36-49`; `src/routes/webhooks.ts:34-56` - **Severity:** **medium** — both routes fully parse attacker-controlled JSON with no request-size limit, and event payloads/descriptions/types have no stored-size bounds. An authenticated or compromised tenant can consume process memory and disk, blocking all tenants on the single SQLite database. - **Recommended fix:** Reject requests whose declared or streamed body exceeds a configured limit before parsing; enforce maximum lengths for event type, serialized payload, URL, and description; return `413` for body limits and `400`/`422` for field limits. Enforce tenant quotas or retention for stored events/deliveries so repeated valid-size requests cannot fill the disk. ### 10. Expected client errors are returned as generic HTTP 500 responses - **Location:** `src/server.ts:68-75`; error types at `src/lib/http.ts:10-35` - **Severity:** **medium** — authentication, validation, and not-found errors already carry 401/400/404 statuses, but the top-level handler ignores them. Clients cannot distinguish malformed requests from outages, monitoring reports false server failures, and retrying clients may unnecessarily repeat invalid requests. - **Recommended fix:** In the catch block, detect `err instanceof HttpError` and return its status with a safe error body; log expected 4xx errors at an appropriate level without stack traces. Keep unknown errors as a generic 500 and log a request/correlation ID. Add route tests for missing/invalid keys, validation failures, missing resources, and unexpected exceptions. ### 11. Invalid webhook input reports success - **Location:** `src/routes/webhooks.ts:36-49` - **Severity:** **medium** — missing or unparsable URLs return HTTP 200. Clients using `Response.ok`, retry policy, or metrics will record a successful registration even though no webhook exists. - **Recommended fix:** Throw `ValidationError` (or return a 400/422 response) for both cases. Implement finding 10 at the same time so thrown validation errors retain their 4xx status, and standardize the error response shape across both branches. ### 12. Pagination accepts non-finite values and webhook pagination skips the first page - **Location:** `src/routes/webhooks.ts:8-20`; the same parsing pattern at `src/routes/events.ts:8-13` and `src/routes/deliveries.ts:7-13` - **Severity:** **medium** — `/webhooks?page=1` uses an offset of 10, so the newest ten records are never returned on any page. Values such as `page=abc` become `NaN` (because `Math.max` does not sanitize `NaN`) and reach SQLite, producing a 500; arbitrarily large page values can also produce invalid/non-safe offsets. - **Recommended fix:** Centralize page parsing: accept only digit strings that convert to a safe integer within an explicit maximum, reject invalid input with a validation error, and compute `(page - 1) * PAGE_SIZE`. Add first-page, second-page, zero, negative, fractional, nonnumeric, and overflow tests for all three list endpoints. ### 13. The immediate dispatch nudge creates an unhandled promise rejection - **Location:** `src/routes/events.ts:52-58` - **Severity:** **medium** — `dispatchPendingDeliveries()` is neither awaited nor caught. Database failures and other errors become unhandled rejections; depending on runtime policy they can destabilize the process, and in all cases the immediate dispatch failure is invisible to operators. - **Recommended fix:** Prefer enqueueing/claiming durable work and let the worker own dispatch. If the nudge remains fire-and-forget, explicitly use `void dispatchPendingDeliveries().catch(...)` with structured logging and a metric. Combine this with finding 3 so the nudge cannot race scheduled or operator-triggered sweeps. ### 14. Runtime configuration is not validated - **Location:** `src/config.ts:1-16`; consumers at `src/server.ts:17-28` and `src/jobs/dispatcher.ts:37` - **Severity:** **medium** — malformed, zero, negative, or non-finite numeric environment values are accepted. This can prevent startup, create near-continuous timers, disable useful retries, or make request timeouts invalid. If `INTERNAL_TOKEN` is omitted, the service silently uses a publicly known default token in every environment. - **Recommended fix:** Parse and validate configuration once at startup with explicit ranges: valid TCP port, positive bounded intervals/timeouts, and a positive integer attempt limit. Fail startup with a clear variable-specific error. Require `INTERNAL_TOKEN` when `NODE_ENV=production` (or equivalent deployment mode); keep any development default behind an explicit development-only branch. ### 15. Internal-token comparison is not constant-time - **Location:** `src/middleware/auth.ts:36-40`; existing helper at `src/lib/crypto.ts:16-29` - **Severity:** **low** — the shared maintenance credential is compared with `!==`, whose work may vary with the matching prefix. Exploitation over a network is difficult and the protected operation is limited, so this is lower impact than the default-token and authorization issues. - **Recommended fix:** After rejecting a missing header, compare the supplied token with `safeCompare` from `lib/crypto.ts`. Also use a sufficiently long random production token and rate-limit failed attempts at the service or ingress layer. ### 16. Delivery listing performs an N+1 query pattern - **Location:** `src/routes/deliveries.ts:13-22`; query at `src/db.ts:237-247` - **Severity:** **low** — each page performs one list query plus up to 25 individual webhook lookups. This adds avoidable SQLite work and request latency under account activity. - **Recommended fix:** Join `webhooks` in `listDeliveriesByAccount` and select the destination URL in the same query (using a left join if historical rows may lack a webhook), then return a typed projection. Add a query/result test covering deleted or missing webhook rows. ### 17. “Today” statistics use the server's local midnight against UTC timestamps - **Location:** `src/routes/deliveries.ts:27-40`; timestamp storage at `src/db.ts:197,218,225` - **Severity:** **low** — `setHours` computes local midnight while stored timestamps are UTC ISO strings. On hosts outside UTC, the endpoint includes part of the prior/next UTC day and omits part of the requested day. - **Recommended fix:** Define the API's day semantics explicitly. If it means UTC today, use `setUTCHours(0, 0, 0, 0)`. If it means an account-local day, store an account timezone and calculate both UTC start and end boundaries for that zone, then query `created_at >= start AND created_at < end`. Add tests around positive/negative offsets and daylight-saving transitions if account-local behavior is chosen. ## Remediation plan 1. **Immediately block data and network boundary attacks:** fix the SQL injection (finding 1) and SSRF (finding 2). These are the direct cross-tenant/internal-network security risks. Rotate/review credentials and inspect access logs if this code has been exposed, because code changes cannot determine whether either flaw was already abused. 2. **Make dispatch ownership safe before increasing throughput:** implement the atomic claim/lease and expired-lease recovery model (finding 3), then add bounded concurrency (finding 8) and safely handle the ingestion nudge (finding 13). The concurrency fix explicitly depends on atomic claims. Deploy schema additions for lease owner/expiry first in a backward-compatible migration, deploy compatible workers next, and only then enable concurrent processing. During rollout, avoid mixed versions that interpret all `sending` rows as immediately retryable. 3. **Protect delivery integrity:** make event creation/fan-out transactional and add the delivery uniqueness constraint (finding 5), then add ingestion idempotency (finding 7). Both require production migrations. Audit/deduplicate existing `(event_id, webhook_id)` rows before creating the unique index; add the nullable idempotency column/index first, deploy code that populates it, and coordinate clients before making an idempotency key mandatory. 4. **Stop permanent bad work:** introduce a terminal outcome for deactivated/missing dependencies and backfill current poison rows (finding 6). If status values are constrained in production, this is a schema-first coordinated rollout; otherwise the code and backfill can ship together after workers understand the new state. 5. **Restore authentication and operational safety:** replace or bound the API-key cache (finding 4), validate configuration and remove the production default internal token (finding 14), and use constant-time comparison (finding 15). Coordinate the token change with the caller of `/internal/dispatch-now`; deploy the new secret to both sides without relying on the checked-in fallback. 6. **Harden the HTTP contract and resource limits:** preserve `HttpError` statuses (finding 10), return proper URL validation errors (finding 11), validate pagination (finding 12), and enforce body/field/storage limits (finding 9). Publish any newly enforced limits to clients before rollout if existing payloads may exceed them. 7. **Finish lower-risk correctness and efficiency work:** collapse the delivery N+1 query (finding 16) and define/fix day-boundary semantics (finding 17). The latter needs product/API agreement if “today” is intended to be account-local rather than UTC. Before each rollout, add focused regression tests for the affected behavior and observe queue depth, oldest pending age, retry counts, duplicate-claim conflicts, and terminal failures. The database/worker changes should be rehearsed against a copy of production data and deployed with a rollback path; they are not safe as an uncoordinated code-only release.
Diff
diff --git a/AUDIT.md b/AUDIT.mdnew file mode 100644index 0000000..17dd714--- /dev/null+++ b/AUDIT.md@@ -0,0 +1,119 @@+# Webhook Relay Audit++Scope: every tracked file in this fixture was read. The findings below are limited to concrete behavior in the current implementation.++## Findings++### 1. Event filtering is SQL-injectable and breaks tenant isolation++- **Location:** `src/routes/events.ts:15-30`, especially line 24+- **Severity:** **critical** — an authenticated tenant controls `type`, which is interpolated into SQL. Crafted input can alter the query and disclose another tenant's event payloads (and potentially other database data via `UNION`). This is a direct confidentiality boundary violation.+- **Recommended fix:** Keep the SQL text static and bind `type` as a parameter (`... AND type = ?`, then append `type` to `params`). Prefer moving this query into `db.ts` so all database access follows the existing parameterized-query pattern. Add tests with quotes, SQL operators, and `UNION` payloads that prove results remain scoped to `account.id`.++### 2. Webhook URLs permit server-side request forgery++- **Location:** `src/routes/webhooks.ts:44-57`; outbound use at `src/jobs/dispatcher.ts:30-38`+- **Severity:** **high** — any authenticated account can register an arbitrary absolute URL, after which the service performs a POST from its trusted network. This permits blind access to loopback, private/link-local networks, and cloud metadata or internal HTTP services, including side-effecting requests.+- **Recommended fix:** At registration and again immediately before dispatch, require `https:` (or an explicitly documented protocol allowlist), reject credentials and nonstandard ports unless required, resolve the hostname, and reject every resolved loopback, private, link-local, multicast, and reserved address for both IPv4 and IPv6. Pin or revalidate the resolved address when connecting so DNS rebinding cannot bypass the check, and apply the same validation to every redirect or disable redirects. If private destinations are a required feature, implement an explicit per-destination allowlist rather than accepting arbitrary URLs.++### 3. In-flight and pending deliveries can be sent more than once concurrently++- **Location:** `src/db.ts:206-215,266-283`; `src/jobs/dispatcher.ts:5-9,26-38`; `src/jobs/retry.ts:5-11`; `src/server.ts:17-23,61-64`; `src/routes/events.ts:52-58`+- **Severity:** **high** — selecting work and changing it to `sending` are separate operations with no conditional claim. Timer sweeps, the internal route, and event-ingestion nudges can overlap and select the same `pending` row. In addition, every `sending` row has `next_attempt_at IS NULL`, so the retry sweep treats a currently executing request as immediately retryable. Duplicate POSTs can therefore run concurrently and cause duplicate downstream side effects.+- **Recommended fix:** Replace `listPendingDeliveries` plus unconditional `markSending` with an atomic claim/lease operation in a transaction: select eligible IDs, conditionally update only rows still eligible to `sending`, set a unique lease owner and lease expiry, and return only rows successfully claimed. Retry only expired leases, never all `sending` rows. Make completion updates conditional on the lease owner so a stale worker cannot overwrite a newer attempt. Also prevent overlapping sweeps in-process (a mutex or self-scheduling loop), while retaining database-level claims for multi-process safety.++### 4. API-key rotation or account revocation does not take effect in a running process++- **Location:** `src/middleware/auth.ts:6-29`+- **Severity:** **high** — successful credentials and their account records are cached forever. After an API key is rotated, deleted, or its account is disabled in the database, the old key remains authorized until every service process restarts.+- **Recommended fix:** Do not cache credential validation, or use a bounded cache with a short TTL plus explicit invalidation integrated into the key-rotation/revocation path. Cache only the minimum account identity, cap entries, and verify revocation semantics with a test that authenticates, rotates/deletes the key, and confirms the old key is rejected without restarting the process.++### 5. Event creation and fan-out are not atomic++- **Location:** `src/db.ts:181-204`; orchestration at `src/routes/events.ts:45-50`+- **Severity:** **high** — the event insert commits before delivery rows are created, and delivery inserts are individually committed. A database error or process exit can leave an event with no deliveries or only a partial fan-out, with no code that reconciles the missing rows. Accepted events can be silently lost for some subscribers.+- **Recommended fix:** Add a single database function that starts a SQLite transaction, inserts the event, snapshots the active webhook IDs, inserts all corresponding deliveries, and commits only after all inserts succeed. Roll back the entire operation on error. Add a uniqueness constraint on `(event_id, webhook_id)` so reconciliation or retries cannot create duplicate delivery rows; introducing that constraint requires checking and deduplicating existing rows first in production.++### 6. Missing webhook/event rows and deactivated webhooks retry forever++- **Location:** `src/jobs/dispatcher.ts:18-23`; `src/db.ts:224-235,272-283`+- **Severity:** **medium** — this failure branch calls `markFailed` without incrementing `attemptCount`. Such rows always satisfy `attempt_count < maxAttempts`, so the retry job reschedules them indefinitely. Deactivating a webhook with queued deliveries creates permanent retry/database load.+- **Recommended fix:** Model non-retryable outcomes explicitly (for example `cancelled` or terminal `failed`) and clear `next_attempt_at` for missing/deactivated dependencies. Exclude terminal rows from retry selection. If a schema status constraint is added, deploy the schema change before code writes the new status and backfill existing affected rows as a coordinated migration.++### 7. Event ingestion has no idempotency mechanism++- **Location:** `src/routes/events.ts:34-60`; schema at `src/db.ts:77-95`+- **Severity:** **medium** — a client that times out after the insert and retries creates a second event and a second full set of deliveries. Network retries are normal, so downstream webhook consumers can receive duplicates even without a worker crash.+- **Recommended fix:** Require or support an idempotency key on `POST /events`, persist it with the account and request fingerprint, and enforce a unique `(account_id, idempotency_key)` constraint. In one transaction, return the original result for an identical replay and reject reuse with a different body. This needs a production schema migration deployed before enabling the new write path; clients need a coordinated rollout if the header becomes mandatory.++### 8. Dispatch is serial and can fall permanently behind++- **Location:** `src/jobs/dispatcher.ts:5-9`; `src/jobs/retry.ts:9-11`; timeout at `src/config.ts:15`+- **Severity:** **medium** — each batch awaits up to 50 deliveries sequentially. At the default eight-second timeout, one batch can take roughly 400 seconds while new work arrives every five seconds. This creates unbounded delivery latency and also makes overlapping sweeps much more likely.+- **Recommended fix:** After implementing the atomic claim/lease in finding 3, process claimed deliveries with bounded concurrency (for example a worker pool of 5-10, configurable based on capacity) using per-request timeouts. Measure queue depth and oldest-pending age, and tune batch/concurrency limits from those metrics. Do not add parallelism before atomic claiming, because that would amplify duplicate sends.++### 9. Unbounded request bodies can exhaust memory and grow the database without limit++- **Location:** `src/routes/events.ts:36-49`; `src/routes/webhooks.ts:34-56`+- **Severity:** **medium** — both routes fully parse attacker-controlled JSON with no request-size limit, and event payloads/descriptions/types have no stored-size bounds. An authenticated or compromised tenant can consume process memory and disk, blocking all tenants on the single SQLite database.+- **Recommended fix:** Reject requests whose declared or streamed body exceeds a configured limit before parsing; enforce maximum lengths for event type, serialized payload, URL, and description; return `413` for body limits and `400`/`422` for field limits. Enforce tenant quotas or retention for stored events/deliveries so repeated valid-size requests cannot fill the disk.++### 10. Expected client errors are returned as generic HTTP 500 responses++- **Location:** `src/server.ts:68-75`; error types at `src/lib/http.ts:10-35`+- **Severity:** **medium** — authentication, validation, and not-found errors already carry 401/400/404 statuses, but the top-level handler ignores them. Clients cannot distinguish malformed requests from outages, monitoring reports false server failures, and retrying clients may unnecessarily repeat invalid requests.+- **Recommended fix:** In the catch block, detect `err instanceof HttpError` and return its status with a safe error body; log expected 4xx errors at an appropriate level without stack traces. Keep unknown errors as a generic 500 and log a request/correlation ID. Add route tests for missing/invalid keys, validation failures, missing resources, and unexpected exceptions.++### 11. Invalid webhook input reports success++- **Location:** `src/routes/webhooks.ts:36-49`+- **Severity:** **medium** — missing or unparsable URLs return HTTP 200. Clients using `Response.ok`, retry policy, or metrics will record a successful registration even though no webhook exists.+- **Recommended fix:** Throw `ValidationError` (or return a 400/422 response) for both cases. Implement finding 10 at the same time so thrown validation errors retain their 4xx status, and standardize the error response shape across both branches.++### 12. Pagination accepts non-finite values and webhook pagination skips the first page++- **Location:** `src/routes/webhooks.ts:8-20`; the same parsing pattern at `src/routes/events.ts:8-13` and `src/routes/deliveries.ts:7-13`+- **Severity:** **medium** — `/webhooks?page=1` uses an offset of 10, so the newest ten records are never returned on any page. Values such as `page=abc` become `NaN` (because `Math.max` does not sanitize `NaN`) and reach SQLite, producing a 500; arbitrarily large page values can also produce invalid/non-safe offsets.+- **Recommended fix:** Centralize page parsing: accept only digit strings that convert to a safe integer within an explicit maximum, reject invalid input with a validation error, and compute `(page - 1) * PAGE_SIZE`. Add first-page, second-page, zero, negative, fractional, nonnumeric, and overflow tests for all three list endpoints.++### 13. The immediate dispatch nudge creates an unhandled promise rejection++- **Location:** `src/routes/events.ts:52-58`+- **Severity:** **medium** — `dispatchPendingDeliveries()` is neither awaited nor caught. Database failures and other errors become unhandled rejections; depending on runtime policy they can destabilize the process, and in all cases the immediate dispatch failure is invisible to operators.+- **Recommended fix:** Prefer enqueueing/claiming durable work and let the worker own dispatch. If the nudge remains fire-and-forget, explicitly use `void dispatchPendingDeliveries().catch(...)` with structured logging and a metric. Combine this with finding 3 so the nudge cannot race scheduled or operator-triggered sweeps.++### 14. Runtime configuration is not validated++- **Location:** `src/config.ts:1-16`; consumers at `src/server.ts:17-28` and `src/jobs/dispatcher.ts:37`+- **Severity:** **medium** — malformed, zero, negative, or non-finite numeric environment values are accepted. This can prevent startup, create near-continuous timers, disable useful retries, or make request timeouts invalid. If `INTERNAL_TOKEN` is omitted, the service silently uses a publicly known default token in every environment.+- **Recommended fix:** Parse and validate configuration once at startup with explicit ranges: valid TCP port, positive bounded intervals/timeouts, and a positive integer attempt limit. Fail startup with a clear variable-specific error. Require `INTERNAL_TOKEN` when `NODE_ENV=production` (or equivalent deployment mode); keep any development default behind an explicit development-only branch.++### 15. Internal-token comparison is not constant-time++- **Location:** `src/middleware/auth.ts:36-40`; existing helper at `src/lib/crypto.ts:16-29`+- **Severity:** **low** — the shared maintenance credential is compared with `!==`, whose work may vary with the matching prefix. Exploitation over a network is difficult and the protected operation is limited, so this is lower impact than the default-token and authorization issues.+- **Recommended fix:** After rejecting a missing header, compare the supplied token with `safeCompare` from `lib/crypto.ts`. Also use a sufficiently long random production token and rate-limit failed attempts at the service or ingress layer.++### 16. Delivery listing performs an N+1 query pattern++- **Location:** `src/routes/deliveries.ts:13-22`; query at `src/db.ts:237-247`+- **Severity:** **low** — each page performs one list query plus up to 25 individual webhook lookups. This adds avoidable SQLite work and request latency under account activity.+- **Recommended fix:** Join `webhooks` in `listDeliveriesByAccount` and select the destination URL in the same query (using a left join if historical rows may lack a webhook), then return a typed projection. Add a query/result test covering deleted or missing webhook rows.++### 17. “Today” statistics use the server's local midnight against UTC timestamps++- **Location:** `src/routes/deliveries.ts:27-40`; timestamp storage at `src/db.ts:197,218,225`+- **Severity:** **low** — `setHours` computes local midnight while stored timestamps are UTC ISO strings. On hosts outside UTC, the endpoint includes part of the prior/next UTC day and omits part of the requested day.+- **Recommended fix:** Define the API's day semantics explicitly. If it means UTC today, use `setUTCHours(0, 0, 0, 0)`. If it means an account-local day, store an account timezone and calculate both UTC start and end boundaries for that zone, then query `created_at >= start AND created_at < end`. Add tests around positive/negative offsets and daylight-saving transitions if account-local behavior is chosen.++## Remediation plan++1. **Immediately block data and network boundary attacks:** fix the SQL injection (finding 1) and SSRF (finding 2). These are the direct cross-tenant/internal-network security risks. Rotate/review credentials and inspect access logs if this code has been exposed, because code changes cannot determine whether either flaw was already abused.+2. **Make dispatch ownership safe before increasing throughput:** implement the atomic claim/lease and expired-lease recovery model (finding 3), then add bounded concurrency (finding 8) and safely handle the ingestion nudge (finding 13). The concurrency fix explicitly depends on atomic claims. Deploy schema additions for lease owner/expiry first in a backward-compatible migration, deploy compatible workers next, and only then enable concurrent processing. During rollout, avoid mixed versions that interpret all `sending` rows as immediately retryable.+3. **Protect delivery integrity:** make event creation/fan-out transactional and add the delivery uniqueness constraint (finding 5), then add ingestion idempotency (finding 7). Both require production migrations. Audit/deduplicate existing `(event_id, webhook_id)` rows before creating the unique index; add the nullable idempotency column/index first, deploy code that populates it, and coordinate clients before making an idempotency key mandatory.+4. **Stop permanent bad work:** introduce a terminal outcome for deactivated/missing dependencies and backfill current poison rows (finding 6). If status values are constrained in production, this is a schema-first coordinated rollout; otherwise the code and backfill can ship together after workers understand the new state.+5. **Restore authentication and operational safety:** replace or bound the API-key cache (finding 4), validate configuration and remove the production default internal token (finding 14), and use constant-time comparison (finding 15). Coordinate the token change with the caller of `/internal/dispatch-now`; deploy the new secret to both sides without relying on the checked-in fallback.+6. **Harden the HTTP contract and resource limits:** preserve `HttpError` statuses (finding 10), return proper URL validation errors (finding 11), validate pagination (finding 12), and enforce body/field/storage limits (finding 9). Publish any newly enforced limits to clients before rollout if existing payloads may exceed them.+7. **Finish lower-risk correctness and efficiency work:** collapse the delivery N+1 query (finding 16) and define/fix day-boundary semantics (finding 17). The latter needs product/API agreement if “today” is intended to be account-local rather than UTC.++Before each rollout, add focused regression tests for the affected behavior and observe queue depth, oldest pending age, retry counts, duplicate-claim conflicts, and terminal failures. The database/worker changes should be rehearsed against a copy of production data and deployed with a rollback path; they are not safe as an uncoordinated code-only release.
Transcript
{
"type": "thread.started",
"thread_id": "01a0760d-8ab5-72d1-9aa2-6e9e2c8b4df7"
}{
"type": "turn.started"
}{
"type": "item.completed",
"item": {
"id": "item_0",
"type": "error",
"message": "Skill descriptions were shortened to fit the skills context budget. Codex can still see every skill, but some descriptions are shorter. Disable unused skills or plugins to leave more room for the rest."
}
}{
"type": "item.completed",
"item": {
"id": "item_1",
"type": "agent_message",
"text": "I’m using the production-audit skill because this is a repository-wide, evidence-based service audit. I’ll first inventory and read every file, then trace concrete failure paths and write only `AUDIT.md`."
}
}{
"type": "item.started",
"item": {
"id": "item_2",
"type": "command_execution",
"command": "/bin/zsh -lc \"sed -n '1,240p' /Users/decod3rslabs/.agents/skills/production-audit/SKILL.md\"",
"aggregated_output": "",
"exit_code": null,
"status": "in_progress"
}
}{
"type": "item.completed",
"item": {
"id": "item_2",
"type": "command_execution",
"command": "/bin/zsh -lc \"sed -n '1,240p' /Users/decod3rslabs/.agents/skills/production-audit/SKILL.md\"",
"aggregated_output": "---\nname: production-audit\ndescription: Audit an application for production readiness using local evidence from code, CI, config, migrations, runtime checks, observability, and deployment paths. Use before launch, after risky merges, or when asked whether an app is ready to ship.\nmetadata:\n version: \"1.0.1\"\n tags: \"production, audit, launch, deployment, reliability\"\n---\n\n# Production Audit\n\nAssess whether an application is safe to ship by inspecting the release surface and naming production risks.\n\n## Contract\n\nInputs:\n\n- Repository, branch, PR, release candidate, or deployed URL\n- Optional launch-critical flows, test account, environment notes, or CI run\n\nOutputs:\n\n- Ship/block recommendation with score and evidence\n- Blockers, high-value fixes, missing evidence, and next action\n- Concrete file, command, CI, or URL references\n\nCreates/Modifies:\n\n- None in audit mode\n- Follow-up fixes only when explicitly requested\n\nExternal Side Effects:\n\n- Read-only local commands and authorized HTTP/browser checks\n- No source upload, destructive migration, production write, or scanner run by default\n\nConfirmation Required:\n\n- Before credentialed production actions, remote scanner use, deploys, migrations, data changes, or user-impacting tests\n\nDelegates To:\n\n- `security-audit` for application security findings\n- `deploy` or `deployment-composer` for release mechanics\n- `release-pr-gates` for GitHub release promotion\n- `playwright-e2e-init` for missing launch-critical browser coverage; `test-runner` for existing tests\n\n## When to Use\n\n- User asks \"is this production ready?\", \"what breaks in prod?\", \"ready to\n ship?\", \"audit this release\", or \"what did we miss?\"\n- A launch, demo, customer rollout, or investor walkthrough is close.\n- CI is green but production risk still needs review.\n- A risky PR merged or a dependency upgrade landed.\n- A deployed staging or preview URL needs a readiness pass.\n\nNot a compliance, legal, financial, medical, or security certification — engineering release triage only.\n\n## Evidence Order\n\nStart with cheap local evidence:\n\n```bash\ngit status --short --branch\ngit log --oneline --decorate -20\ngit diff --stat origin/main...HEAD\n```\n\nThen inspect the surfaces that actually exist:\n\n- package scripts, build commands, CI workflows, and release scripts\n- API routes, auth middleware, webhooks, workers, cron jobs, and queues\n- migrations, seeds, backfills, rollback notes, and data access policies\n- environment variable documentation and startup validation\n- payment, email, storage, AI, and external-provider boundaries\n- observability, logging, health checks, dashboards, and alert ownership\n- E2E or smoke coverage for launch-critical user paths\n- deployed URL checks when a URL is in scope\n\nDo not call a release healthy just because CI is green.\n\n## Risk Lenses\n\n### Security and Auth\n\n- Are sensitive routes protected server-side?\n- Are authorization checks tenant-aware and applied near data access?\n- Are secrets absent from client bundles, logs, examples, and committed files?\n- Are uploads, CORS, CSRF, rate limits, and input validation appropriate?\n- Do agent or AI surfaces isolate untrusted content from privileged tools?\n\n### Data Integrity\n\n- Can migrations run forward safely?\n- Is there a rollback, recovery, or backup path for high-impact changes?\n- Are destructive backfills staged and idempotent?\n- Are retries safe for writes, jobs, and webhooks?\n- Do sandbox, staging, and production schemas match the code assumptions?\n\n### Payments and Webhooks\n\n- Are webhook signatures verified before trusting payload fields?\n- Are fulfillment handlers idempotent for duplicate delivery?\n- Are out-of-order and replayed events handled?\n- Are test and live credentials separated?\n- Is customer-visible billing state recoverable after provider failure?\n\n### Operations\n\n- Can the app start from a clean checkout with documented commands?\n- Are required environment variables named and validated at startup?\n- Is there a health check that proves dependencies are reachable?\n- Are logs useful without leaking secrets or personal data?\n- Is there a clear deploy, rollback, and incident-owner path?\n\n### User Experience\n\n- Are launch-critical paths covered on desktop and mobile?\n- Are loading, empty, error, and permission-denied states usable?\n- Do forms handle invalid input, slow requests, and double submits?\n- Is there a recovery or support path when a critical operation fails?\n\n## Scoring\n\nUse scores to force prioritization:\n\n| Score | Verdict |\n| --- | --- |\n| 0-49 | Blocked: do not ship until blockers are fixed |\n| 50-69 | Risky: internal beta or small rollout only |\n| 70-84 | Launchable with caveats: ship if owners accept named risks |\n| 85-100 | Strong: no obvious launch blockers from available evidence |\n\nCap at `69` if any are true:\n\n- auth or authorization is missing for sensitive data\n- payment or fulfillment webhooks are not idempotent\n- required migrations cannot run safely\n- secrets are exposed in client bundles, logs, or committed files\n- no rollback or recovery path exists for a high-impact release\n\nCap at `84` if CI is not green or the launch-critical path was not tested end\nto end.\n\n## Output Format\n\nLead with one sentence:\n\n```text\nProduction audit: 76/100, launchable with caveats, with webhook idempotency and rollback docs as the two risks to fix before public launch.\n```\n\nThen list:\n\n- `Blockers`: must-fix items before deploy\n- `High-value fixes`: next improvements by impact\n- `Evidence checked`: files, commands, CI, URLs, or PRs inspected\n- `Evidence missing`: what would change confidence\n- `Next action`: one concrete fix or verification step\n\nIf no blockers are found, still state the evidence boundary.\n\n## Anti-Patterns\n\n- Running unpinned remote scanners as the default audit path.\n- Uploading private source, secrets, customer data, or topology externally\n without explicit approval.\n- Giving a score without naming evidence.\n- Treating staging smoke tests as proof that data migrations are safe.\n- Ending with a generic summary instead of the next concrete release action.\n",
"exit_code": 0,
"status": "completed"
}
}{
"type": "item.started",
"item": {
"id": "item_3",
"type": "command_execution",
"command": "/bin/zsh -lc \"pwd && rg --files -uu -g '\"'!AUDIT.md'\"' | sort && git status --short --branch 2>/dev/null || true\"",
"aggregated_output": "",
"exit_code": null,
"status": "in_progress"
}
}{
"type": "item.completed",
"item": {
"id": "item_3",
"type": "command_execution",
"command": "/bin/zsh -lc \"pwd && rg --files -uu -g '\"'!AUDIT.md'\"' | sort && git status --short --branch 2>/dev/null || true\"",
"aggregated_output": "/Users/decod3rslabs/www/shipshitdev/public/benchmark/.runs/v2026.09-smoke__planning-audit--planted-defects__codex--gpt-5.6-sol--low__1/workspace\n.git/COMMIT_EDITMSG\n.git/HEAD\n.git/config\n.git/description\n.git/hooks/applypatch-msg.sample\n.git/hooks/commit-msg.sample\n.git/hooks/fsmonitor-watchman.sample\n.git/hooks/post-update.sample\n.git/hooks/pre-applypatch.sample\n.git/hooks/pre-commit.sample\n.git/hooks/pre-merge-commit.sample\n.git/hooks/pre-push.sample\n.git/hooks/pre-rebase.sample\n.git/hooks/pre-receive.sample\n.git/hooks/prepare-commit-msg.sample\n.git/hooks/push-to-checkout.sample\n.git/hooks/sendemail-validate.sample\n.git/hooks/update.sample\n.git/index\n.git/info/exclude\n.git/logs/HEAD\n.git/logs/refs/heads/main\n.git/objects/01/715057b350aca20ed1a1f4fdbb7af138ab2ac1\n.git/objects/04/37eb1f5910718469287092aa17a7e236a68fc8\n.git/objects/18/21a591e08b308c377365e7134d1dfc6ef56216\n.git/objects/23/70bd795bb1b9f52e6d6ffa6f7d63ec3072c355\n.git/objects/2b/ca995acc81477cb3fbe762c626815663546b3c\n.git/objects/3f/b3daf10f6e2da7773708c6e227386f6a5f9a1d\n.git/objects/4f/2e45cf98268279d667e3ba7c214d6a60943b3a\n.git/objects/55/0610884426f23ab3edd4e4b0c451e4aac199ed\n.git/objects/5e/23d30113981195da37d2d500601aa514063678\n.git/objects/64/4fc43a1b8221884108d3625c17d907b748150b\n.git/objects/6b/5bb956dd25ff2fc4e588b7a6d1fa85363e01e7\n.git/objects/71/56d6d02a40afaa62eaf8b47363a472bdd24c0e\n.git/objects/74/3bccfea10997b63be88c824867a78103fc5590\n.git/objects/92/e25943fae9f71908f28997bc7ea7097c4ccc01\n.git/objects/93/9a53e2b91c239d793435731ba5d5d393b666ad\n.git/objects/a6/fe53a0db0d8027318f166256a2e3771144116c\n.git/objects/b4/07a689174e90cbf4bd843a5c8fee48b8d8738e\n.git/objects/ce/ab934d25224af2bd97e96d213473427d80a211\n.git/objects/d3/50a2640c84ba4782a7628e053af994f003ad8d\n.git/objects/d7/afcd2d5820313a68957d32312d79351831caee\n.git/objects/e3/009995d8c68144f6b7bf660cfc0641c5b2de4d\n.git/objects/ee/8027e2ac9ed78688472f80a2679f080857fa99\n.git/objects/f4/2d9e32be6ab742c7305fe7ad072d516f6f7373\n.git/refs/heads/main\n.gitignore\nREADME.md\npackage.json\nsrc/config.ts\nsrc/db.ts\nsrc/jobs/dispatcher.ts\nsrc/jobs/retry.ts\nsrc/lib/crypto.ts\nsrc/lib/http.ts\nsrc/middleware/auth.ts\nsrc/routes/deliveries.ts\nsrc/routes/events.ts\nsrc/routes/webhooks.ts\nsrc/server.ts\nsrc/types.ts\ntsconfig.json\n## main\n",
"exit_code": 0,
"status": "completed"
}
}{
"type": "item.completed",
"item": {
"id": "item_4",
"type": "agent_message",
"text": "The fixture contains 13 tracked service/config files plus `.gitignore`; there is no repository memory directory. I’m now reading all tracked content with line numbers and will cross-check call sites before assigning severity."
}
}{
"type": "item.started",
"item": {
"id": "item_5",
"type": "command_execution",
"command": "/bin/zsh -lc 'for f in $(git ls-files); do wc -l \"$f\"; done\nfor f in $(git ls-files); do echo \"===== $f =====\"; nl -ba \"$f\"; done'",
"aggregated_output": "",
"exit_code": null,
"status": "in_progress"
}
}{
"type": "item.completed",
"item": {
"id": "item_5",
"type": "command_execution",
"command": "/bin/zsh -lc 'for f in $(git ls-files); do wc -l \"$f\"; done\nfor f in $(git ls-files); do echo \"===== $f =====\"; nl -ba \"$f\"; done'",
"aggregated_output": " 4 .gitignore\n 52 README.md\n 9 package.json\n 16 src/config.ts\n 284 src/db.ts\n 48 src/jobs/dispatcher.ts\n 12 src/jobs/retry.ts\n 29 src/lib/crypto.ts\n 35 src/lib/http.ts\n 41 src/middleware/auth.ts\n 41 src/routes/deliveries.ts\n 61 src/routes/events.ts\n 73 src/routes/webhooks.ts\n 79 src/server.ts\n 45 src/types.ts\n 21 tsconfig.json\n===== .gitignore =====\n 1\tnode_modules\n 2\t*.db\n 3\tbun.lock\n 4\t.DS_Store\n===== README.md =====\n 1\t# Webhook Relay\n 2\t\n 3\tA small internal service that accepts events from other internal systems and delivers\n 4\tthem, over HTTP, to the webhook endpoints each account has registered. Think of it as a\n 5\tlightweight version of what Stripe or GitHub run to fan a single event out to every\n 6\tsubscriber: an event comes in once, and this service takes care of signing it, retrying\n 7\tfailed deliveries, and tracking delivery status per webhook.\n 8\t\n 9\t## Concepts\n 10\t\n 11\t- **Account** — a tenant, identified by an API key sent as `X-Api-Key`.\n 12\t- **Webhook** — a URL an account has registered to receive events, plus a per-webhook\n 13\t signing secret used to HMAC-sign every delivery (`X-Relay-Signature` header).\n 14\t- **Event** — a typed payload ingested via `POST /events`. Ingesting an event creates one\n 15\t delivery per active webhook on the account.\n 16\t- **Delivery** — one attempt (and its retries) to deliver a single event to a single\n 17\t webhook. Deliveries move through `pending -> sending -> delivered` or `failed`.\n 18\t\n 19\t## API\n 20\t\n 21\t- `POST /events` — ingest a new event (`{ type, payload }`) and fan it out to the\n 22\t account's active webhooks.\n 23\t- `GET /events?type=&page=` — list ingested events, optionally filtered by type.\n 24\t- `POST /webhooks` — register a new webhook (`{ url, description? }`).\n 25\t- `GET /webhooks?page=` — list the account's registered webhooks.\n 26\t- `GET /webhooks/:id` — fetch a single webhook.\n 27\t- `DELETE /webhooks/:id` — deactivate a webhook; it stops receiving new deliveries.\n 28\t- `GET /deliveries?page=` — list delivery attempts across the account's webhooks.\n 29\t- `GET /deliveries/stats/today` — delivery counts by status for the current day.\n 30\t- `POST /internal/dispatch-now` — operator-only route to trigger an immediate dispatch\n 31\t sweep, guarded by a shared `X-Internal-Token` header.\n 32\t\n 33\t## Background jobs\n 34\t\n 35\tTwo sweeps run on an interval (`server.ts`):\n 36\t\n 37\t- **Dispatcher** — sends every `pending` delivery.\n 38\t- **Retry** — re-sends deliveries that didn't complete on the first attempt, with a\n 39\t backoff window before each retry, up to `MAX_DELIVERY_ATTEMPTS`.\n 40\t\n 41\t## Running locally\n 42\t\n 43\tAccounts and their API keys are provisioned out of band (there is no signup route in\n 44\tthis service); this repo assumes a row already exists in the `accounts` table.\n 45\t\n 46\t```\n 47\tbun install\n 48\tbun run src/server.ts\n 49\t```\n 50\t\n 51\tData is stored in a local `bun:sqlite` database file (`DB_PATH`, defaults to\n 52\t`relay.db`).\n===== package.json =====\n 1\t{\n 2\t \"name\": \"planted-defects-fixture\",\n 3\t \"private\": true,\n 4\t \"type\": \"module\",\n 5\t \"devDependencies\": {\n 6\t \"typescript\": \"7.0.2\",\n 7\t \"@types/bun\": \"1.4.1\"\n 8\t }\n 9\t}\n===== src/config.ts =====\n 1\texport const config = {\n 2\t port: Number(process.env.PORT ?? 3000),\n 3\t dbPath: process.env.DB_PATH ?? \"relay.db\",\n 4\t\n 5\t // Shared secret for the internal maintenance route (see routes wired in server.ts).\n 6\t // In production this comes from the deploy environment; the fallback here is only for\n 7\t // local development.\n 8\t internalToken: process.env.INTERNAL_TOKEN ?? \"dev-internal-token\",\n 9\t\n 10\t // How often the background sweeps run.\n 11\t dispatchIntervalMs: Number(process.env.DISPATCH_INTERVAL_MS ?? 5000),\n 12\t retryIntervalMs: Number(process.env.RETRY_INTERVAL_MS ?? 15000),\n 13\t\n 14\t maxDeliveryAttempts: Number(process.env.MAX_DELIVERY_ATTEMPTS ?? 5),\n 15\t webhookTimeoutMs: Number(process.env.WEBHOOK_TIMEOUT_MS ?? 8000),\n 16\t};\n===== src/db.ts =====\n 1\timport { Database } from \"bun:sqlite\";\n 2\timport { config } from \"./config\";\n 3\timport { generateId } from \"./lib/crypto\";\n 4\timport type { Account, Delivery, DeliveryStats, Event, Webhook } from \"./types\";\n 5\t\n 6\tinterface AccountRow {\n 7\t id: string;\n 8\t name: string;\n 9\t api_key: string;\n 10\t created_at: string;\n 11\t}\n 12\t\n 13\tinterface WebhookRow {\n 14\t id: string;\n 15\t account_id: string;\n 16\t url: string;\n 17\t secret: string;\n 18\t description: string | null;\n 19\t is_active: number;\n 20\t created_at: string;\n 21\t}\n 22\t\n 23\tinterface EventRow {\n 24\t id: string;\n 25\t account_id: string;\n 26\t type: string;\n 27\t payload: string;\n 28\t created_at: string;\n 29\t}\n 30\t\n 31\tinterface DeliveryRow {\n 32\t id: string;\n 33\t event_id: string;\n 34\t webhook_id: string;\n 35\t status: string;\n 36\t attempt_count: number;\n 37\t response_status: number | null;\n 38\t last_attempt_at: string | null;\n 39\t next_attempt_at: string | null;\n 40\t created_at: string;\n 41\t}\n 42\t\n 43\tinterface DeliveryStatusCountRow {\n 44\t status: string;\n 45\t count: number;\n 46\t}\n 47\t\n 48\tlet db: Database | null = null;\n 49\t\n 50\texport function getDb(): Database {\n 51\t if (!db) {\n 52\t db = new Database(config.dbPath, { create: true });\n 53\t db.exec(\"PRAGMA journal_mode = WAL;\");\n 54\t }\n 55\t return db;\n 56\t}\n 57\t\n 58\texport function initSchema(): void {\n 59\t getDb().exec(`\n 60\t CREATE TABLE IF NOT EXISTS accounts (\n 61\t id TEXT PRIMARY KEY,\n 62\t name TEXT NOT NULL,\n 63\t api_key TEXT NOT NULL UNIQUE,\n 64\t created_at TEXT NOT NULL\n 65\t );\n 66\t\n 67\t CREATE TABLE IF NOT EXISTS webhooks (\n 68\t id TEXT PRIMARY KEY,\n 69\t account_id TEXT NOT NULL,\n 70\t url TEXT NOT NULL,\n 71\t secret TEXT NOT NULL,\n 72\t description TEXT,\n 73\t is_active INTEGER NOT NULL DEFAULT 1,\n 74\t created_at TEXT NOT NULL\n 75\t );\n 76\t\n 77\t CREATE TABLE IF NOT EXISTS events (\n 78\t id TEXT PRIMARY KEY,\n 79\t account_id TEXT NOT NULL,\n 80\t type TEXT NOT NULL,\n 81\t payload TEXT NOT NULL,\n 82\t created_at TEXT NOT NULL\n 83\t );\n 84\t\n 85\t CREATE TABLE IF NOT EXISTS deliveries (\n 86\t id TEXT PRIMARY KEY,\n 87\t event_id TEXT NOT NULL,\n 88\t webhook_id TEXT NOT NULL,\n 89\t status TEXT NOT NULL DEFAULT 'pending',\n 90\t attempt_count INTEGER NOT NULL DEFAULT 0,\n 91\t response_status INTEGER,\n 92\t last_attempt_at TEXT,\n 93\t next_attempt_at TEXT,\n 94\t created_at TEXT NOT NULL\n 95\t );\n 96\t\n 97\t CREATE INDEX IF NOT EXISTS idx_deliveries_status ON deliveries(status);\n 98\t CREATE INDEX IF NOT EXISTS idx_events_account ON events(account_id);\n 99\t CREATE INDEX IF NOT EXISTS idx_webhooks_account ON webhooks(account_id);\n 100\t `);\n 101\t}\n 102\t\n 103\tfunction rowToAccount(row: AccountRow): Account {\n 104\t return { id: row.id, name: row.name, apiKey: row.api_key, createdAt: row.created_at };\n 105\t}\n 106\t\n 107\tfunction rowToWebhook(row: WebhookRow): Webhook {\n 108\t return {\n 109\t id: row.id,\n 110\t accountId: row.account_id,\n 111\t url: row.url,\n 112\t secret: row.secret,\n 113\t description: row.description,\n 114\t isActive: !!row.is_active,\n 115\t createdAt: row.created_at,\n 116\t };\n 117\t}\n 118\t\n 119\tfunction rowToEvent(row: EventRow): Event {\n 120\t return { id: row.id, accountId: row.account_id, type: row.type, payload: row.payload, createdAt: row.created_at };\n 121\t}\n 122\t\n 123\tfunction rowToDelivery(row: DeliveryRow): Delivery {\n 124\t return {\n 125\t id: row.id,\n 126\t eventId: row.event_id,\n 127\t webhookId: row.webhook_id,\n 128\t status: row.status as Delivery[\"status\"],\n 129\t attemptCount: row.attempt_count,\n 130\t responseStatus: row.response_status,\n 131\t lastAttemptAt: row.last_attempt_at,\n 132\t nextAttemptAt: row.next_attempt_at,\n 133\t createdAt: row.created_at,\n 134\t };\n 135\t}\n 136\t\n 137\texport function getAccountByApiKey(apiKey: string): Account | null {\n 138\t const row = getDb().query(\"SELECT * FROM accounts WHERE api_key = ?\").get(apiKey) as AccountRow | null;\n 139\t return row ? rowToAccount(row) : null;\n 140\t}\n 141\t\n 142\texport function createWebhook(input: {\n 143\t accountId: string;\n 144\t url: string;\n 145\t secret: string;\n 146\t description: string | null;\n 147\t}): Webhook {\n 148\t const id = generateId(\"wh\");\n 149\t const createdAt = new Date().toISOString();\n 150\t getDb()\n 151\t .query(\n 152\t \"INSERT INTO webhooks (id, account_id, url, secret, description, is_active, created_at) VALUES (?, ?, ?, ?, ?, 1, ?)\",\n 153\t )\n 154\t .run(id, input.accountId, input.url, input.secret, input.description, createdAt);\n 155\t return { id, accountId: input.accountId, url: input.url, secret: input.secret, description: input.description, isActive: true, createdAt };\n 156\t}\n 157\t\n 158\texport function listWebhooksByAccount(accountId: string, limit: number, offset: number): Webhook[] {\n 159\t const rows = getDb()\n 160\t .query(\"SELECT * FROM webhooks WHERE account_id = ? ORDER BY created_at DESC LIMIT ? OFFSET ?\")\n 161\t .all(accountId, limit, offset) as WebhookRow[];\n 162\t return rows.map(rowToWebhook);\n 163\t}\n 164\t\n 165\texport function listActiveWebhooksByAccount(accountId: string): Webhook[] {\n 166\t const rows = getDb()\n 167\t .query(\"SELECT * FROM webhooks WHERE account_id = ? AND is_active = 1\")\n 168\t .all(accountId) as WebhookRow[];\n 169\t return rows.map(rowToWebhook);\n 170\t}\n 171\t\n 172\texport function getWebhookById(id: string): Webhook | null {\n 173\t const row = getDb().query(\"SELECT * FROM webhooks WHERE id = ?\").get(id) as WebhookRow | null;\n 174\t return row ? rowToWebhook(row) : null;\n 175\t}\n 176\t\n 177\texport function deactivateWebhook(id: string): void {\n 178\t getDb().query(\"UPDATE webhooks SET is_active = 0 WHERE id = ?\").run(id);\n 179\t}\n 180\t\n 181\texport function createEvent(input: { accountId: string; type: string; payload: string }): Event {\n 182\t const id = generateId(\"evt\");\n 183\t const createdAt = new Date().toISOString();\n 184\t getDb()\n 185\t .query(\"INSERT INTO events (id, account_id, type, payload, created_at) VALUES (?, ?, ?, ?, ?)\")\n 186\t .run(id, input.accountId, input.type, input.payload, createdAt);\n 187\t return { id, accountId: input.accountId, type: input.type, payload: input.payload, createdAt };\n 188\t}\n 189\t\n 190\texport function getEventById(id: string): Event | null {\n 191\t const row = getDb().query(\"SELECT * FROM events WHERE id = ?\").get(id) as EventRow | null;\n 192\t return row ? rowToEvent(row) : null;\n 193\t}\n 194\t\n 195\texport function createDeliveriesForActiveWebhooks(eventId: string, accountId: string): void {\n 196\t const webhooks = listActiveWebhooksByAccount(accountId);\n 197\t const createdAt = new Date().toISOString();\n 198\t const insert = getDb().query(\n 199\t \"INSERT INTO deliveries (id, event_id, webhook_id, status, created_at) VALUES (?, ?, ?, 'pending', ?)\",\n 200\t );\n 201\t for (const webhook of webhooks) {\n 202\t insert.run(generateId(\"dlv\"), eventId, webhook.id, createdAt);\n 203\t }\n 204\t}\n 205\t\n 206\texport function listPendingDeliveries(limit: number): Delivery[] {\n 207\t const rows = getDb()\n 208\t .query(\"SELECT * FROM deliveries WHERE status = 'pending' ORDER BY created_at ASC LIMIT ?\")\n 209\t .all(limit) as DeliveryRow[];\n 210\t return rows.map(rowToDelivery);\n 211\t}\n 212\t\n 213\texport function markSending(id: string): void {\n 214\t getDb().query(\"UPDATE deliveries SET status = 'sending' WHERE id = ?\").run(id);\n 215\t}\n 216\t\n 217\texport function markDelivered(id: string, responseStatus: number): void {\n 218\t const now = new Date().toISOString();\n 219\t getDb()\n 220\t .query(\"UPDATE deliveries SET status = 'delivered', response_status = ?, last_attempt_at = ? WHERE id = ?\")\n 221\t .run(responseStatus, now, id);\n 222\t}\n 223\t\n 224\texport function markFailed(id: string, responseStatus: number, attemptCount = 0): void {\n 225\t const now = new Date().toISOString();\n 226\t const backoffMs = 60_000 * (attemptCount + 1);\n 227\t const nextAttempt = new Date(Date.now() + backoffMs).toISOString();\n 228\t getDb()\n 229\t .query(\n 230\t `UPDATE deliveries\n 231\t SET status = 'failed', response_status = ?, attempt_count = ?, last_attempt_at = ?, next_attempt_at = ?\n 232\t WHERE id = ?`,\n 233\t )\n 234\t .run(responseStatus, attemptCount, now, nextAttempt, id);\n 235\t}\n 236\t\n 237\texport function listDeliveriesByAccount(accountId: string, limit: number, offset: number): Delivery[] {\n 238\t const rows = getDb()\n 239\t .query(\n 240\t `SELECT d.* FROM deliveries d\n 241\t JOIN events e ON e.id = d.event_id\n 242\t WHERE e.account_id = ?\n 243\t ORDER BY d.created_at DESC\n 244\t LIMIT ? OFFSET ?`,\n 245\t )\n 246\t .all(accountId, limit, offset) as DeliveryRow[];\n 247\t return rows.map(rowToDelivery);\n 248\t}\n 249\t\n 250\texport function countDeliveriesByStatusSince(accountId: string, sinceIso: string): DeliveryStats {\n 251\t const rows = getDb()\n 252\t .query(\n 253\t `SELECT d.status as status, COUNT(*) as count FROM deliveries d\n 254\t JOIN events e ON e.id = d.event_id\n 255\t WHERE e.account_id = ? AND d.created_at >= ?\n 256\t GROUP BY d.status`,\n 257\t )\n 258\t .all(accountId, sinceIso) as DeliveryStatusCountRow[];\n 259\t const stats: DeliveryStats = { pending: 0, sending: 0, delivered: 0, failed: 0 };\n 260\t for (const row of rows) {\n 261\t stats[row.status as keyof DeliveryStats] = row.count;\n 262\t }\n 263\t return stats;\n 264\t}\n 265\t\n 266\t/**\n 267\t * Deliveries eligible for a retry sweep. Includes rows still marked `sending` because a\n 268\t * delivery can get stuck there if the process dies between the outbound `fetch` in\n 269\t * jobs/dispatcher.ts and the `markDelivered` call that follows it — see jobs/retry.ts for\n 270\t * why treating those the same as `failed` is not safe.\n 271\t */\n 272\texport function listRetryableDeliveries(nowIso: string, maxAttempts: number): Delivery[] {\n 273\t const rows = getDb()\n 274\t .query(\n 275\t `SELECT * FROM deliveries\n 276\t WHERE status IN ('failed', 'sending')\n 277\t AND attempt_count < ?\n 278\t AND (next_attempt_at IS NULL OR next_attempt_at <= ?)\n 279\t ORDER BY next_attempt_at ASC\n 280\t LIMIT 50`,\n 281\t )\n 282\t .all(maxAttempts, nowIso) as DeliveryRow[];\n 283\t return rows.map(rowToDelivery);\n 284\t}\n===== src/jobs/dispatcher.ts =====\n 1\timport { config } from \"../config\";\n 2\timport { getEventById, getWebhookById, listPendingDeliveries, markDelivered, markFailed, markSending } from \"../db\";\n 3\timport { signPayload } from \"../lib/crypto\";\n 4\t\n 5\texport async function dispatchPendingDeliveries(): Promise<void> {\n 6\t const pending = listPendingDeliveries(50);\n 7\t for (const delivery of pending) {\n 8\t await sendDelivery(delivery.id, delivery.webhookId, delivery.eventId, delivery.attemptCount);\n 9\t }\n 10\t}\n 11\t\n 12\texport async function sendDelivery(\n 13\t deliveryId: string,\n 14\t webhookId: string,\n 15\t eventId: string,\n 16\t attemptCount: number,\n 17\t): Promise<void> {\n 18\t const webhook = getWebhookById(webhookId);\n 19\t const event = getEventById(eventId);\n 20\t\n 21\t if (!webhook || !event || !webhook.isActive) {\n 22\t markFailed(deliveryId, 0, attemptCount);\n 23\t return;\n 24\t }\n 25\t\n 26\t markSending(deliveryId);\n 27\t const signature = signPayload(webhook.secret, event.payload);\n 28\t\n 29\t try {\n 30\t const res = await fetch(webhook.url, {\n 31\t method: \"POST\",\n 32\t headers: {\n 33\t \"content-type\": \"application/json\",\n 34\t \"x-relay-signature\": signature,\n 35\t },\n 36\t body: event.payload,\n 37\t signal: AbortSignal.timeout(config.webhookTimeoutMs),\n 38\t });\n 39\t\n 40\t if (res.ok) {\n 41\t markDelivered(deliveryId, res.status);\n 42\t } else {\n 43\t markFailed(deliveryId, res.status, attemptCount + 1);\n 44\t }\n 45\t } catch {\n 46\t markFailed(deliveryId, 0, attemptCount + 1);\n 47\t }\n 48\t}\n===== src/jobs/retry.ts =====\n 1\timport { config } from \"../config\";\n 2\timport { listRetryableDeliveries } from \"../db\";\n 3\timport { sendDelivery } from \"./dispatcher\";\n 4\t\n 5\texport async function retryFailedDeliveries(): Promise<void> {\n 6\t const now = new Date().toISOString();\n 7\t const retryable = listRetryableDeliveries(now, config.maxDeliveryAttempts);\n 8\t\n 9\t for (const delivery of retryable) {\n 10\t await sendDelivery(delivery.id, delivery.webhookId, delivery.eventId, delivery.attemptCount);\n 11\t }\n 12\t}\n===== src/lib/crypto.ts =====\n 1\timport { createHmac, randomUUID, timingSafeEqual } from \"node:crypto\";\n 2\t\n 3\texport function generateId(prefix: string): string {\n 4\t return `${prefix}_${randomUUID().replace(/-/g, \"\")}`;\n 5\t}\n 6\t\n 7\texport function generateSecret(): string {\n 8\t return randomUUID().replace(/-/g, \"\");\n 9\t}\n 10\t\n 11\t/** HMAC-SHA256 signature for an outbound delivery, sent as the `x-relay-signature` header. */\n 12\texport function signPayload(secret: string, payload: string): string {\n 13\t return createHmac(\"sha256\", secret).update(payload).digest(\"hex\");\n 14\t}\n 15\t\n 16\t/**\n 17\t * Constant-time string comparison for secrets and tokens. Callers that compare a\n 18\t * caller-supplied credential against a stored value should use this instead of `===`\n 19\t * or `!==`, which short-circuit on the first differing byte and leak timing information\n 20\t * about how much of the credential was guessed correctly.\n 21\t */\n 22\texport function safeCompare(a: string, b: string): boolean {\n 23\t const bufA = Buffer.from(a);\n 24\t const bufB = Buffer.from(b);\n 25\t if (bufA.length !== bufB.length) {\n 26\t return false;\n 27\t }\n 28\t return timingSafeEqual(bufA, bufB);\n 29\t}\n===== src/lib/http.ts =====\n 1\texport function json(data: unknown, status = 200): Response {\n 2\t return Response.json(data, { status });\n 3\t}\n 4\t\n 5\t/**\n 6\t * Base class for errors that carry the HTTP status they should map to. Route handlers\n 7\t * throw these (or a subclass) and let the top-level request handler translate them into\n 8\t * a response.\n 9\t */\n 10\texport class HttpError extends Error {\n 11\t status: number;\n 12\t\n 13\t constructor(status: number, message: string) {\n 14\t super(message);\n 15\t this.status = status;\n 16\t }\n 17\t}\n 18\t\n 19\texport class ValidationError extends HttpError {\n 20\t constructor(message: string) {\n 21\t super(400, message);\n 22\t }\n 23\t}\n 24\t\n 25\texport class NotFoundError extends HttpError {\n 26\t constructor(message = \"not found\") {\n 27\t super(404, message);\n 28\t }\n 29\t}\n 30\t\n 31\texport class UnauthorizedError extends HttpError {\n 32\t constructor(message = \"unauthorized\") {\n 33\t super(401, message);\n 34\t }\n 35\t}\n===== src/middleware/auth.ts =====\n 1\timport { config } from \"../config\";\n 2\timport { getAccountByApiKey } from \"../db\";\n 3\timport { UnauthorizedError } from \"../lib/http\";\n 4\timport type { Account } from \"../types\";\n 5\t\n 6\t// Caches account lookups by API key so a hot path (every authenticated request) doesn't\n 7\t// hit sqlite each time. Entries are added on every successful lookup and are never\n 8\t// removed — there is no max size, no TTL, and no invalidation when an account rotates\n 9\t// its key.\n 10\tconst keyCache = new Map<string, Account>();\n 11\t\n 12\texport async function requireAuth(req: Request): Promise<Account> {\n 13\t const key = req.headers.get(\"x-api-key\");\n 14\t if (!key) {\n 15\t throw new UnauthorizedError(\"missing x-api-key header\");\n 16\t }\n 17\t\n 18\t const cached = keyCache.get(key);\n 19\t if (cached) {\n 20\t return cached;\n 21\t }\n 22\t\n 23\t const account = getAccountByApiKey(key);\n 24\t if (!account) {\n 25\t throw new UnauthorizedError(\"invalid api key\");\n 26\t }\n 27\t\n 28\t keyCache.set(key, account);\n 29\t return account;\n 30\t}\n 31\t\n 32\t/**\n 33\t * Guards the internal maintenance route (`/internal/dispatch-now`) with a static shared\n 34\t * token instead of a per-account API key.\n 35\t */\n 36\texport function requireInternalToken(req: Request): void {\n 37\t const token = req.headers.get(\"x-internal-token\") ?? \"\";\n 38\t if (token !== config.internalToken) {\n 39\t throw new UnauthorizedError(\"invalid internal token\");\n 40\t }\n 41\t}\n===== src/routes/deliveries.ts =====\n 1\timport { countDeliveriesByStatusSince, getWebhookById, listDeliveriesByAccount } from \"../db\";\n 2\timport { json } from \"../lib/http\";\n 3\timport { requireAuth } from \"../middleware/auth\";\n 4\t\n 5\tconst PAGE_SIZE = 25;\n 6\t\n 7\texport async function listDeliveries(req: Request): Promise<Response> {\n 8\t const account = await requireAuth(req);\n 9\t const url = new URL(req.url);\n 10\t const page = Math.max(1, Number(url.searchParams.get(\"page\") ?? \"1\"));\n 11\t const offset = (page - 1) * PAGE_SIZE;\n 12\t\n 13\t const deliveries = listDeliveriesByAccount(account.id, PAGE_SIZE, offset);\n 14\t\n 15\t // Looks up the destination URL for each delivery one at a time instead of joining\n 16\t // `webhooks` into the query in db.ts's `listDeliveriesByAccount`. A full page issues\n 17\t // 1 (page) + PAGE_SIZE (25) queries instead of 1, and the cost scales linearly with\n 18\t // page size and account activity.\n 19\t const enriched = deliveries.map((delivery) => {\n 20\t const webhook = getWebhookById(delivery.webhookId);\n 21\t return { ...delivery, webhookUrl: webhook?.url ?? null };\n 22\t });\n 23\t\n 24\t return json({ deliveries: enriched, page, pageSize: PAGE_SIZE });\n 25\t}\n 26\t\n 27\texport async function deliveryStatsToday(req: Request): Promise<Response> {\n 28\t const account = await requireAuth(req);\n 29\t\n 30\t // `deliveries.created_at` is stored as a UTC ISO-8601 timestamp (see db.ts, which uses\n 31\t // `new Date().toISOString()` throughout). `setHours(0, 0, 0, 0)` resets to midnight in\n 32\t // the server process's *local* timezone, not UTC. Whenever the local offset is\n 33\t // non-zero, this boundary doesn't line up with UTC midnight: deliveries from the start\n 34\t // or end of the actual UTC day are miscounted as belonging to \"yesterday\" or\n 35\t // \"tomorrow\" depending on the offset's sign.\n 36\t const startOfDay = new Date();\n 37\t startOfDay.setHours(0, 0, 0, 0);\n 38\t\n 39\t const stats = countDeliveriesByStatusSince(account.id, startOfDay.toISOString());\n 40\t return json({ stats, since: startOfDay.toISOString() });\n 41\t}\n===== src/routes/events.ts =====\n 1\timport { createDeliveriesForActiveWebhooks, createEvent, getDb } from \"../db\";\n 2\timport { json, ValidationError } from \"../lib/http\";\n 3\timport { dispatchPendingDeliveries } from \"../jobs/dispatcher\";\n 4\timport { requireAuth } from \"../middleware/auth\";\n 5\t\n 6\tconst PAGE_SIZE = 20;\n 7\t\n 8\texport async function listEvents(req: Request): Promise<Response> {\n 9\t const account = await requireAuth(req);\n 10\t const url = new URL(req.url);\n 11\t const type = url.searchParams.get(\"type\");\n 12\t const page = Math.max(1, Number(url.searchParams.get(\"page\") ?? \"1\"));\n 13\t const offset = (page - 1) * PAGE_SIZE;\n 14\t\n 15\t const params: unknown[] = [account.id];\n 16\t let query = \"SELECT id, type, payload, created_at FROM events WHERE account_id = ?\";\n 17\t\n 18\t if (type) {\n 19\t // `type` is a free-text query parameter interpolated directly into the SQL string\n 20\t // instead of being bound as a parameter, unlike `account.id` and the limit/offset\n 21\t // below. A value such as `x' OR '1'='1` turns the filter into a no-op and returns\n 22\t // every account's events; a value with a UNION SELECT can pull columns (including\n 23\t // `payload`) from other tables entirely.\n 24\t query += ` AND type = '${type}'`;\n 25\t }\n 26\t\n 27\t query += \" ORDER BY created_at DESC LIMIT ? OFFSET ?\";\n 28\t params.push(PAGE_SIZE, offset);\n 29\t\n 30\t const rows = getDb().query(query).all(...params);\n 31\t return json({ events: rows, page, pageSize: PAGE_SIZE });\n 32\t}\n 33\t\n 34\texport async function ingestEvent(req: Request): Promise<Response> {\n 35\t const account = await requireAuth(req);\n 36\t const body = await req.json().catch(() => null);\n 37\t\n 38\t if (!body || typeof body.type !== \"string\" || body.type.length === 0) {\n 39\t throw new ValidationError(\"type is required and must be a non-empty string\");\n 40\t }\n 41\t if (body.payload === undefined) {\n 42\t throw new ValidationError(\"payload is required\");\n 43\t }\n 44\t\n 45\t const event = createEvent({\n 46\t accountId: account.id,\n 47\t type: body.type,\n 48\t payload: JSON.stringify(body.payload),\n 49\t });\n 50\t createDeliveriesForActiveWebhooks(event.id, account.id);\n 51\t\n 52\t // Nudge the dispatch sweep so the event goes out immediately instead of waiting for the\n 53\t // next interval, but the call is neither awaited nor given a `.catch()`. If\n 54\t // `dispatchPendingDeliveries` throws (a locked database, a malformed webhook URL from\n 55\t // `new URL()`, etc.) the rejection is unhandled and the failure is never logged or\n 56\t // surfaced — the event is created successfully but silently waits for the next\n 57\t // scheduled sweep in server.ts instead.\n 58\t dispatchPendingDeliveries();\n 59\t\n 60\t return json({ event }, 201);\n 61\t}\n===== src/routes/webhooks.ts =====\n 1\timport { createWebhook, deactivateWebhook, getWebhookById, listWebhooksByAccount } from \"../db\";\n 2\timport { generateSecret } from \"../lib/crypto\";\n 3\timport { json, NotFoundError, ValidationError } from \"../lib/http\";\n 4\timport { requireAuth } from \"../middleware/auth\";\n 5\t\n 6\tconst PAGE_SIZE = 10;\n 7\t\n 8\texport async function listWebhooks(req: Request): Promise<Response> {\n 9\t const account = await requireAuth(req);\n 10\t const url = new URL(req.url);\n 11\t const page = Math.max(1, Number(url.searchParams.get(\"page\") ?? \"1\"));\n 12\t\n 13\t // Pages are 1-indexed at the API boundary (page=1 is the first page), but the offset\n 14\t // here is computed as `page * PAGE_SIZE` instead of `(page - 1) * PAGE_SIZE`. For\n 15\t // page=1 that skips the first PAGE_SIZE rows entirely, so the newest `PAGE_SIZE`\n 16\t // webhooks are never returned by this endpoint at any page number.\n 17\t const offset = page * PAGE_SIZE;\n 18\t\n 19\t const webhooks = listWebhooksByAccount(account.id, PAGE_SIZE, offset);\n 20\t return json({ webhooks, page, pageSize: PAGE_SIZE });\n 21\t}\n 22\t\n 23\texport async function getWebhookHandler(req: Request, id: string): Promise<Response> {\n 24\t const account = await requireAuth(req);\n 25\t const webhook = getWebhookById(id);\n 26\t if (!webhook || webhook.accountId !== account.id) {\n 27\t throw new NotFoundError(\"webhook not found\");\n 28\t }\n 29\t return json({ webhook });\n 30\t}\n 31\t\n 32\texport async function createWebhookHandler(req: Request): Promise<Response> {\n 33\t const account = await requireAuth(req);\n 34\t const body = await req.json().catch(() => null);\n 35\t\n 36\t if (!body || typeof body.url !== \"string\" || body.url.length === 0) {\n 37\t // A missing or malformed `url` is a client mistake, but the response here is a 200\n 38\t // with an `error` field in the body instead of a 4xx status. A caller that checks\n 39\t // `res.ok` (or just the status code, as most HTTP clients and monitoring do) will\n 40\t // treat this as a successful webhook registration.\n 41\t return json({ error: \"url is required\" }, 200);\n 42\t }\n 43\t\n 44\t let parsedUrl: URL;\n 45\t try {\n 46\t parsedUrl = new URL(body.url);\n 47\t } catch {\n 48\t return json({ error: \"url must be a valid absolute URL\" }, 200);\n 49\t }\n 50\t\n 51\t const description = typeof body.description === \"string\" ? body.description : null;\n 52\t const webhook = createWebhook({\n 53\t accountId: account.id,\n 54\t url: parsedUrl.toString(),\n 55\t secret: generateSecret(),\n 56\t description,\n 57\t });\n 58\t\n 59\t return json({ webhook }, 201);\n 60\t}\n 61\t\n 62\texport async function deactivateWebhookHandler(req: Request, id: string): Promise<Response> {\n 63\t const account = await requireAuth(req);\n 64\t const webhook = getWebhookById(id);\n 65\t if (!webhook || webhook.accountId !== account.id) {\n 66\t throw new NotFoundError(\"webhook not found\");\n 67\t }\n 68\t if (!webhook.isActive) {\n 69\t throw new ValidationError(\"webhook is already inactive\");\n 70\t }\n 71\t deactivateWebhook(id);\n 72\t return json({ ok: true });\n 73\t}\n===== src/server.ts =====\n 1\timport { config } from \"./config\";\n 2\timport { initSchema } from \"./db\";\n 3\timport { deliveryStatsToday, listDeliveries } from \"./routes/deliveries\";\n 4\timport { ingestEvent, listEvents } from \"./routes/events\";\n 5\timport {\n 6\t createWebhookHandler,\n 7\t deactivateWebhookHandler,\n 8\t getWebhookHandler,\n 9\t listWebhooks,\n 10\t} from \"./routes/webhooks\";\n 11\timport { dispatchPendingDeliveries } from \"./jobs/dispatcher\";\n 12\timport { retryFailedDeliveries } from \"./jobs/retry\";\n 13\timport { requireInternalToken } from \"./middleware/auth\";\n 14\t\n 15\tinitSchema();\n 16\t\n 17\tsetInterval(() => {\n 18\t dispatchPendingDeliveries().catch((err) => console.error(\"dispatch sweep failed\", err));\n 19\t}, config.dispatchIntervalMs);\n 20\t\n 21\tsetInterval(() => {\n 22\t retryFailedDeliveries().catch((err) => console.error(\"retry sweep failed\", err));\n 23\t}, config.retryIntervalMs);\n 24\t\n 25\tconst WEBHOOK_ID_ROUTE = /^\\/webhooks\\/([^/]+)$/;\n 26\t\n 27\tBun.serve({\n 28\t port: config.port,\n 29\t async fetch(req) {\n 30\t const url = new URL(req.url);\n 31\t\n 32\t try {\n 33\t if (req.method === \"GET\" && url.pathname === \"/webhooks\") {\n 34\t return await listWebhooks(req);\n 35\t }\n 36\t if (req.method === \"POST\" && url.pathname === \"/webhooks\") {\n 37\t return await createWebhookHandler(req);\n 38\t }\n 39\t\n 40\t const webhookMatch = url.pathname.match(WEBHOOK_ID_ROUTE);\n 41\t if (webhookMatch) {\n 42\t const id = webhookMatch[1]!;\n 43\t if (req.method === \"GET\") return await getWebhookHandler(req, id);\n 44\t if (req.method === \"DELETE\") return await deactivateWebhookHandler(req, id);\n 45\t }\n 46\t\n 47\t if (req.method === \"GET\" && url.pathname === \"/events\") {\n 48\t return await listEvents(req);\n 49\t }\n 50\t if (req.method === \"POST\" && url.pathname === \"/events\") {\n 51\t return await ingestEvent(req);\n 52\t }\n 53\t\n 54\t if (req.method === \"GET\" && url.pathname === \"/deliveries\") {\n 55\t return await listDeliveries(req);\n 56\t }\n 57\t if (req.method === \"GET\" && url.pathname === \"/deliveries/stats/today\") {\n 58\t return await deliveryStatsToday(req);\n 59\t }\n 60\t\n 61\t if (req.method === \"POST\" && url.pathname === \"/internal/dispatch-now\") {\n 62\t requireInternalToken(req);\n 63\t await dispatchPendingDeliveries();\n 64\t return Response.json({ ok: true });\n 65\t }\n 66\t\n 67\t return Response.json({ error: \"not found\" }, { status: 404 });\n 68\t } catch (err) {\n 69\t // Every error thrown by a route handler — including `ValidationError` (400,\n 70\t // client's fault) and `UnauthorizedError`/`NotFoundError` from lib/http.ts, each of\n 71\t // which already carries the right `status` — is flattened to a generic 500 here.\n 72\t // The `err.status` that HttpError subclasses carry is never read.\n 73\t console.error(err);\n 74\t return Response.json({ error: \"internal server error\" }, { status: 500 });\n 75\t }\n 76\t },\n 77\t});\n 78\t\n 79\tconsole.log(`webhook relay listening on :${config.port}`);\n===== src/types.ts =====\n 1\texport interface Account {\n 2\t id: string;\n 3\t name: string;\n 4\t apiKey: string;\n 5\t createdAt: string;\n 6\t}\n 7\t\n 8\texport interface Webhook {\n 9\t id: string;\n 10\t accountId: string;\n 11\t url: string;\n 12\t secret: string;\n 13\t description: string | null;\n 14\t isActive: boolean;\n 15\t createdAt: string;\n 16\t}\n 17\t\n 18\texport interface Event {\n 19\t id: string;\n 20\t accountId: string;\n 21\t type: string;\n 22\t payload: string;\n 23\t createdAt: string;\n 24\t}\n 25\t\n 26\texport type DeliveryStatus = \"pending\" | \"sending\" | \"delivered\" | \"failed\";\n 27\t\n 28\texport interface Delivery {\n 29\t id: string;\n 30\t eventId: string;\n 31\t webhookId: string;\n 32\t status: DeliveryStatus;\n 33\t attemptCount: number;\n 34\t responseStatus: number | null;\n 35\t lastAttemptAt: string | null;\n 36\t nextAttemptAt: string | null;\n 37\t createdAt: string;\n 38\t}\n 39\t\n 40\texport interface DeliveryStats {\n 41\t pending: number;\n 42\t sending: number;\n 43\t delivered: number;\n 44\t failed: number;\n 45\t}\n===== tsconfig.json =====\n 1\t{\n 2\t \"compilerOptions\": {\n 3\t \"target\": \"ESNext\",\n 4\t \"module\": \"ESNext\",\n 5\t \"moduleResolution\": \"bundler\",\n 6\t \"moduleDetection\": \"force\",\n 7\t \"lib\": [\"ESNext\"],\n 8\t \"types\": [\"bun\"],\n 9\t \"strict\": true,\n 10\t \"noUncheckedIndexedAccess\": true,\n 11\t \"noImplicitOverride\": true,\n 12\t \"noFallthroughCasesInSwitch\": true,\n 13\t \"allowImportingTsExtensions\": true,\n 14\t \"verbatimModuleSyntax\": true,\n 15\t \"esModuleInterop\": true,\n 16\t \"forceConsistentCasingInFileNames\": true,\n 17\t \"skipLibCheck\": true,\n 18\t \"noEmit\": true\n 19\t },\n 20\t \"include\": [\"src\"]\n 21\t}\n",
"exit_code": 0,
"status": "completed"
}
}{
"type": "item.completed",
"item": {
"id": "item_6",
"type": "agent_message",
"text": "Cross-file tracing confirms several issues compound each other: retry sweeps can resend an in-flight request, dispatch invocations can overlap and claim the same pending row, and deactivated webhooks enter an endless retry loop. I’m consolidating related symptoms into implementable root-cause findings and separating changes that require schema/data rollout."
}
}{
"type": "item.started",
"item": {
"id": "item_7",
"type": "file_change",
"changes": [
{
"path": "/Users/decod3rslabs/www/shipshitdev/public/benchmark/.runs/v2026.09-smoke__planning-audit--planted-defects__codex--gpt-5.6-sol--low__1/workspace/AUDIT.md",
"kind": "add"
}
],
"status": "in_progress"
}
}{
"type": "item.completed",
"item": {
"id": "item_7",
"type": "file_change",
"changes": [
{
"path": "/Users/decod3rslabs/www/shipshitdev/public/benchmark/.runs/v2026.09-smoke__planning-audit--planted-defects__codex--gpt-5.6-sol--low__1/workspace/AUDIT.md",
"kind": "add"
}
],
"status": "completed"
}
}{
"type": "item.started",
"item": {
"id": "item_8",
"type": "command_execution",
"command": "/bin/zsh -lc \"test -f AUDIT.md && wc -l AUDIT.md && sed -n '1,40p' AUDIT.md && git status --short && git diff -- AUDIT.md\"",
"aggregated_output": "",
"exit_code": null,
"status": "in_progress"
}
}{
"type": "item.completed",
"item": {
"id": "item_8",
"type": "command_execution",
"command": "/bin/zsh -lc \"test -f AUDIT.md && wc -l AUDIT.md && sed -n '1,40p' AUDIT.md && git status --short && git diff -- AUDIT.md\"",
"aggregated_output": " 119 AUDIT.md\n# Webhook Relay Audit\n\nScope: every tracked file in this fixture was read. The findings below are limited to concrete behavior in the current implementation.\n\n## Findings\n\n### 1. Event filtering is SQL-injectable and breaks tenant isolation\n\n- **Location:** `src/routes/events.ts:15-30`, especially line 24\n- **Severity:** **critical** — an authenticated tenant controls `type`, which is interpolated into SQL. Crafted input can alter the query and disclose another tenant's event payloads (and potentially other database data via `UNION`). This is a direct confidentiality boundary violation.\n- **Recommended fix:** Keep the SQL text static and bind `type` as a parameter (`... AND type = ?`, then append `type` to `params`). Prefer moving this query into `db.ts` so all database access follows the existing parameterized-query pattern. Add tests with quotes, SQL operators, and `UNION` payloads that prove results remain scoped to `account.id`.\n\n### 2. Webhook URLs permit server-side request forgery\n\n- **Location:** `src/routes/webhooks.ts:44-57`; outbound use at `src/jobs/dispatcher.ts:30-38`\n- **Severity:** **high** — any authenticated account can register an arbitrary absolute URL, after which the service performs a POST from its trusted network. This permits blind access to loopback, private/link-local networks, and cloud metadata or internal HTTP services, including side-effecting requests.\n- **Recommended fix:** At registration and again immediately before dispatch, require `https:` (or an explicitly documented protocol allowlist), reject credentials and nonstandard ports unless required, resolve the hostname, and reject every resolved loopback, private, link-local, multicast, and reserved address for both IPv4 and IPv6. Pin or revalidate the resolved address when connecting so DNS rebinding cannot bypass the check, and apply the same validation to every redirect or disable redirects. If private destinations are a required feature, implement an explicit per-destination allowlist rather than accepting arbitrary URLs.\n\n### 3. In-flight and pending deliveries can be sent more than once concurrently\n\n- **Location:** `src/db.ts:206-215,266-283`; `src/jobs/dispatcher.ts:5-9,26-38`; `src/jobs/retry.ts:5-11`; `src/server.ts:17-23,61-64`; `src/routes/events.ts:52-58`\n- **Severity:** **high** — selecting work and changing it to `sending` are separate operations with no conditional claim. Timer sweeps, the internal route, and event-ingestion nudges can overlap and select the same `pending` row. In addition, every `sending` row has `next_attempt_at IS NULL`, so the retry sweep treats a currently executing request as immediately retryable. Duplicate POSTs can therefore run concurrently and cause duplicate downstream side effects.\n- **Recommended fix:** Replace `listPendingDeliveries` plus unconditional `markSending` with an atomic claim/lease operation in a transaction: select eligible IDs, conditionally update only rows still eligible to `sending`, set a unique lease owner and lease expiry, and return only rows successfully claimed. Retry only expired leases, never all `sending` rows. Make completion updates conditional on the lease owner so a stale worker cannot overwrite a newer attempt. Also prevent overlapping sweeps in-process (a mutex or self-scheduling loop), while retaining database-level claims for multi-process safety.\n\n### 4. API-key rotation or account revocation does not take effect in a running process\n\n- **Location:** `src/middleware/auth.ts:6-29`\n- **Severity:** **high** — successful credentials and their account records are cached forever. After an API key is rotated, deleted, or its account is disabled in the database, the old key remains authorized until every service process restarts.\n- **Recommended fix:** Do not cache credential validation, or use a bounded cache with a short TTL plus explicit invalidation integrated into the key-rotation/revocation path. Cache only the minimum account identity, cap entries, and verify revocation semantics with a test that authenticates, rotates/deletes the key, and confirms the old key is rejected without restarting the process.\n\n### 5. Event creation and fan-out are not atomic\n\n- **Location:** `src/db.ts:181-204`; orchestration at `src/routes/events.ts:45-50`\n- **Severity:** **high** — the event insert commits before delivery rows are created, and delivery inserts are individually committed. A database error or process exit can leave an event with no deliveries or only a partial fan-out, with no code that reconciles the missing rows. Accepted events can be silently lost for some subscribers.\n- **Recommended fix:** Add a single database function that starts a SQLite transaction, inserts the event, snapshots the active webhook IDs, inserts all corresponding deliveries, and commits only after all inserts succeed. Roll back the entire operation on error. Add a uniqueness constraint on `(event_id, webhook_id)` so reconciliation or retries cannot create duplicate delivery rows; introducing that constraint requires checking and deduplicating existing rows first in production.\n\n### 6. Missing webhook/event rows and deactivated webhooks retry forever\n\n- **Location:** `src/jobs/dispatcher.ts:18-23`; `src/db.ts:224-235,272-283`\n- **Severity:** **medium** — this failure branch calls `markFailed` without incrementing `attemptCount`. Such rows always satisfy `attempt_count < maxAttempts`, so the retry job reschedules them indefinitely. Deactivating a webhook with queued deliveries creates permanent retry/database load.\n?? AUDIT.md\n",
"exit_code": 0,
"status": "completed"
}
}{
"type": "item.completed",
"item": {
"id": "item_9",
"type": "agent_message",
"text": "Created [AUDIT.md](/Users/decod3rslabs/www/shipshitdev/public/benchmark/.runs/v2026.09-smoke__planning-audit--planted-defects__codex--gpt-5.6-sol--low__1/workspace/AUDIT.md) with 17 evidence-backed findings and a sequenced remediation plan.\n\nEvery tracked service file was reviewed. No existing files were modified; only `AUDIT.md` was added."
}
}{
"type": "turn.completed",
"usage": {
"input_tokens": 192376,
"cached_input_tokens": 161152,
"cache_write_input_tokens": 0,
"output_tokens": 5723,
"reasoning_output_tokens": 985
}
}Notes
- codex: no turn cap flag; enforced only by the timebox
- checklist objective scoring happens in "bench judge"