Fork card: fork_too_large (422) for a list whose first entry, or a read whose entry, is past the reply cap #88
Loading…
Reference in a new issue
No description provided.
Delete branch "libby/fork-too-large-draft"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Persona decision 2026-11-11. New refusal code
fork_too_large, HTTP 422, on list (the first entry of a page alone is past the receiver's response budget; error names fork id and order; client continues withc<order>; at order 0 the client has reached the end) and on read (the whole entry is past the reply cap, 65536 bytes in Huginn's daemon; error names the fork id, no cursor).limitentries andnext_cursorresumes below the last entry returned; the too-large fork is skipped by the cursor;request_id_conflictis answer-only and a door conflict on read or list is a door fault shown as 503unavailable; open choices 12 (cap on answers per fork, tracked as libby-body:follow_up:answers-per-fork-cap) and 13 (the read form is a target: Huginn answersResponseTooLarge{bytes,limit}today, which Bifrost must map using the route's fork_id).fork_too_largeadded to the refusal enum.transport.listShortPages(short page, refusal at order 3 continued byc3, refusal at order 0),readTooLarge,doorFaults(read/list/answer with response bytes),doorRefusalsentry at 422. Both judges assert 422 and the exact bytes.Verified: TS governance-vectors 24/24, C#
--filter GovernanceVector21/21; generator output byte-identical; Soul held on origin/main..9394be3d, hand mutations (413, order in the read text, doorFaults bytes) fail both judges. Branch CI was not consulted: the forge's single runner queue was still working through earlier runs.🤖 Generated with Claude Code