You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
id(world): records_read_pages_fit test red on main — panics no entry found for key at world/tests.rs:1169 #5128
thread panicked at src/world/tests.rs:1169:28:
no entry found for key
Evidence
Reproduced on pristine origin/main 7657b97 (clean worktree, cargo test --lib with the test as filter): FAILED, same panic shape as the sibling failures.
pkgs/id/flake.nix builds .#id-web with doCheck=true (checkType ci-check), so this failure — like #5020 and #5021 — fails the Nix check phase and blocks the laptop fleet switch even after the #4522 compile fix lands. #4522 makes the test targets compile again; this issue is one of the three runtime-red lib tests that then remain.
Suspects (unverified)
Recent records.read paging changes: 54ceece fix(id): bound records.read cap pages by the result-event limit (#4888) (#5092), and the id-core world_caps.rs change that arrived with merge de39ee8 (PR #4585). The panic is a map/index lookup miss inside the test at world/tests.rs:1169 — either the test fixture or the paging code disagrees about which key a page is stored under.
Fixed in PR #5167 (merged) — test-only; the paging code and the filed suspects were innocent.
Root cause: the test landed red in #5092. Its probe republished captured results as a single results record, but parse_records caps a record value at MAX_RECORD_VALUE_BYTES (8 KiB), so deliver() refused the publication of the ~64 KiB result record, marked the program unhealthy, and the channel kept the injected records — the test panicked at the results index (tests.rs:1169). Verified directly before fixing: execute returned Ok and a 64,287-byte result event reached delivery; only the readout failed. The sibling BoundsProbe test survives the same readout because its captured results are small.
The probe now shares captured results via an Arc<Mutex<_>> handle and publishes no records; all page assertions (ok, 8 of 16 at the 64,512-byte bound, r00 first, next_after r07) are unchanged and pass.
Activity
Merge pull request #5167 from developing-today/fix/5128-records-read-…
dezren39 commentedon Nov 3, 2026
Fixed in PR #5167 (merged) — test-only; the paging code and the filed suspects were innocent.
Root cause: the test landed red in #5092. Its probe republished captured results as a single
resultsrecord, butparse_recordscaps a record value atMAX_RECORD_VALUE_BYTES(8 KiB), sodeliver()refused the publication of the ~64 KiB result record, marked the program unhealthy, and the channel kept the injected records — the test panicked at theresultsindex (tests.rs:1169). Verified directly before fixing: execute returned Ok and a 64,287-byte result event reached delivery; only the readout failed. The sibling BoundsProbe test survives the same readout because its captured results are small.The probe now shares captured results via an
Arc<Mutex<_>>handle and publishes no records; all page assertions (ok, 8 of 16 at the 64,512-byte bound, r00 first, next_after r07) are unchanged and pass.