Status before error check Debugging Lab

Status before error checkHTTP/APIEasyPreparing workspaceAutosaved

00:00

Incident Dossier

Status before error check

Clients of the public API are getting 200 OK responses even when the upstream service clearly rejected the request. The client SDK then treats the result as success and shows stale data. The gateway response builder looks correct on its own, but the order of operations hides a misclassification.

Initial failing signalAPI returns 200 for a NOT_FOUND resultExpected status 404 when error.code is NOT_FOUND · received status 200 even though result.error is set

Progress

1Reproduce the bugRun checks

2Edit the fixOpen

3Pass checksOpen

4Submit fixOpen

Reproduction Steps

Run npm test.
Inspect the failing assertion: a NOT_FOUND error result returned status 200.
Trace how buildResponse decides the status code.
Reclassify status after the error is inspected.

Focus Mode

Start

src/api.js

Likely area

src/api.js

Progressive hints

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

TopicHTTP/API

DifficultyEasy

Est. time12 min

Workspacecreating

Explorer

Preparing workspace 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$ workspace boot

Workspace booting...