test(web): lock in the engine's real (bare) no_such_endpoint 404 shape - #13
Open
Morgandri1 wants to merge 1 commit into
Open
test(web): lock in the engine's real (bare) no_such_endpoint 404 shape#13Morgandri1 wants to merge 1 commit into
Morgandri1 wants to merge 1 commit into
Conversation
Ingress landed on main (340f318). Its 404 body is a bare {"code":"no_such_endpoint"}, not the {"error":{"code":...,"message":...}} envelope wheel_core::ErrorBody gives every other engine route and that this parser requires by design. errorCode() correctly returns null for it today, so probeVerdict falls through to the generic bodied-404 message instead of the specific one already written for this code. Documents current real behavior rather than intended behavior; flip once SDK's ingress.rs builds a real ErrorBody (reported separately).
|
Deployment failed for project wheel with the following error: Learn More: https://vercel.com/morgandri1s-projects?upgradeToPro=build-rate-limit |
4 tasks
Morgandri1
added a commit
that referenced
this pull request
Sep 7, 2026
PM's objection, and it is correct: a fix that satisfies 'resolves within
60s' by killing and respawning the child every 60s PASSES a bare deadline
assertion while being worse than the bug. The agent leaves 'starting' on
schedule, forever, burning a spawn a minute and delivering nothing. From
outside it is indistinguishable from a real fix.
Three axes now, and the third is the one that tells them apart:
SETTLED — the status afterwards is an answer, not another transitional
state. A deadline that re-enters 'starting' has made the hang
periodic rather than resolved it.
READABLE — a non-empty last_error. A status change with no reason sends
the operator to the logs to reconstruct it, which is the 45
minutes this class costs.
ONE PROC — no second pid across the window (§3c #13). Counted over TIME,
because at any single instant a respawn loop looks exactly
like an agent that is simply starting.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01F1nLndrG8rrdr5ar7P6WkN
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Re-probed the endpoint Test button now that engine-side ingress landed (340f318). Found a real shape mismatch (not a web bug — filing the fix request with SDK separately):
wheel_core::ErrorBody({"error":{"code":...,"message":...}}) — seecrates/wheel-engine/src/api/mod.rs:79.ingress_honestytest mocks the same wrapped shape (crates/wheel-api/tests/ingress_honesty.rs:43).crates/wheel-engine/src/api/ingress.rs:169err()helper instead emits a bare{"code":"no_such_endpoint"}— noerrorwrapper, nomessage.Because
web/src/lib/endpoint-probe.ts'serrorCode()only recognizes the documented envelope (by design — a bare top-levelcodecould belong to an endpoint's own response body, so it can't be loosened without risking a false positive), a real "no endpoint at this path" 404 today falls through to the generic bodied-404 message instead of the specific "no endpoint at this path" one already written for exactly this code. Not misleading, just less specific than intended.This PR documents today's real, verified behavior in a test (rather than asserting the intended-but-not-yet-true behavior), with a comment pointing at exactly what to flip once the engine-side fix lands.
Test plan
pnpm typecheck/pnpm lint/pnpm test(endpoint-probe.test.ts: 16/16, full suite 279/279)