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
make_2611_stages: comparator stages guard on the ArcadeDB wheel and image they do not use, and a pre-START abort strands the chain #439
The comparator stages that make_2611_stages.py writes (default mode, no ArcadeDB arm) guard on the ArcadeDB pair although they never use it, and a guard that fails before the START line leaves the whole chain waiting forever.
Found in the readiness check of 2026-10-22 (drafts qS01-qS09 core, qU01-qU03 second list). Every stage checks that bindings/python/dist/ holds exactly one wheel, the pinned 26.10.2 file, and that dbbench:arcadedb carries that wheel and the JPype pin, and runs verify_pair_c25.sh. A comparator stage builds client, duckdb, pg-age and so on, never arcadedb, and none of its arms imports arcadedb_embedded. On mini today dist/ holds only the 26.10.1 wheel and dbbench:arcadedb is the 2026-10-06 build, so qS01 would abort with "dbbench:arcadedb carries wheel 26.10.1, dist has 26.10.2".
The second problem is what that abort does. The template says "AN ABORT MUST NOT STRAND THE CHAIN" and sets the ALL-DONE trap, but it sets it after the guards, at the START line. A guard before it exits 1 without a marker, so the other eleven stages wait for qS01 ALL-DONE for good. The documented convention (the qMA stages in mini-ab-prep/DESIGN.md: "an EXIT trap set after the wait writes its own marker, so ABORT/SKIP still hand on") is that every ABORT hands on, and the ABORT line goes to STATUS.txt, which mini_watch.sh greps.
Fix, one PR:
The pair's guards (pinned wheel by name and sha256, exactly one wheel in dist/, server image, wheel and JPype read back out of dbbench:arcadedb, verify_pair_c25.sh) go into the stages that run an ArcadeDB arm only. A comparator stage keeps exporting ARCADEDB_WHEEL, ARCADEDB_SERVER_IMAGE and ARCADEDB_ENGINE_COMMIT because the runner takes the three together and land_stage.py keeps the rows whose engine_commit matches the pin, but it exports them after its image build, so build_images.sh no longer bakes the engine under test into the comparator images.
The ALL-DONE trap moves to right after the wait, before the first guard.
--check --drafts lints both rules, tests cover them, the stored draft sha list is rewritten, CAMPAIGN.md says it.
Activity
make_2611_stages: ArcadeDB pair guards only where an ArcadeDB arm run…