Incident Dossier

The token that only fails after deploy

A deployed API returns 401 for tokens that pass local requests. Trace middleware, token parsing, environment loading, and deployment config instead of changing the verifier to accept anything.

Initial failing signalProduction rejects a locally valid tokenExpected behavior: Production token verification uses the deployed AUTH_AUDIENCE value. · actual behavior: The deployment file overwrites the production environment with the staging audience.

Codebase incident

Evidence desk

Codebase Incidents · 4

At 11:06 UTC, a newly deployed API starts returning 401s to a partner integration. The same token is accepted in local development. The token signature is valid and the request reaches the expected route. The clue is the environment-specific audience selected after config files and environment variables are merged.

Customer symptom

Valid partner API calls work locally and fail with 401 in production.

Expected

Explicit deployment environment values override defaults and checked-in local config.

Actual

Checked-in deployment config is merged after process environment and replaces AUTH_AUDIENCE.

Architecture

HTTP requestAuth middlewareToken parserConfig loaderDeployment environmentProtected service

HTTP request → Auth middleware · bearer token
Auth middleware → Token parser · claims
Token parser → Config loader · expected audience
Config loader → Deployment environment · precedence
Auth middleware → Protected service · allow or 401

Logs2

Verification comparison

local env=development token.aud=api-prod expected=api-prod result=200 prod env=production token.aud=api-prod expected=api-staging result=401

auth.middleware

Config source trace

defaults -> environment -> deployment/production.json AUTH_AUDIENCE final=api-staging source=deployment/production.json

config.loader

Metrics1

Auth response split

production 401 rate: 100% for partner route; signature failures: 0; audience mismatch: 100%

auth.metrics

Recent changes

The production audience changed from api-staging to api-prod.
A shared config loader was introduced for local and deployed processes.
The route and token signing key stayed unchanged.

Plausible hypotheses

Token parser rejects a claim — A 401 commonly comes from malformed or expired claims.
Config precedence selects staging — Only production fails and the expected audience differs by environment.
Production middleware is mounted twice — A second auth layer can reject an otherwise valid request.

Progress

1Reproduce the bugRun checks

2Edit the fixOpen

3Pass checksOpen

4Submit fixOpen

Reproduction Steps

Run the test with development and production config inputs.
Trace the token audience and expected audience separately.
Inspect merge order in the config loader.
Preserve strict verification while making environment precedence explicit.

Focus Mode

Do not change the accepted token; compare which source supplies the expected audience in each environment.

Start

README.md
src/http/middleware.js
src/config/loader.js

Likely area

src/config/loader.js
src/auth/verifier.js
src/http/middleware.js

Investigation path

1Reproduce the environment split with the same token.
2Trace expected audience provenance, not just the parser.
3Check config merge precedence and deployment overrides.
4Fix precedence without weakening signature or audience checks.

Repo scale

15 meaningful files
request, middleware, parser, verifier, config sources, route, metrics, and deployment context
One precedence fix

Challenge Coach

Hints reveal broad direction first, then narrow toward the suspect path without showing hidden tests or exact solution code.

TopicAuth & Configuration

DifficultyHard

Est. time35 min

Workspacepreparing

Explorer

Loading files

Evidence Map

Failing signal loaded from challenge API
Workspace files loaded from workspace API
Results rendered only after API run/submit

Autosaved

workspace

Outputread-onlyready$ prepare workspace

Preparing workspace