Round 2 of !130. Both blockers were mine, and one was the same mistake I had just fixed one layer up. 1. fj_pre still took `head -n1`. The verdict folds max over every id, but the PRE-DISPATCH snapshot did not, so an oldest-first payload named an old run as the baseline — and a later poll finding the same body then read the PREVIOUS drill's run as this dispatch's result. That is a false PASS on the take-a-job assertion, strictly worse than the false FAIL entry[0] caused inside the verdict. Both sides now share forgejo_max_task_id, and a test composes them the way the leg does so the pair cannot drift apart again. 2. test/drill.sh copied its pretty-printed fixture from /tmp/fjfix — a scratch path that existed only on the box the fix was built on. Everywhere else the cp failed, the guard returned pending, and the suite was 65/66. The claimed 66/66 was true on one machine. The fixture is written inline like every other one; verified by deleting the scratch dir and running the suite from a clean tree under env -i. Refs #129 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| cli.sh | ||
| db-integration.sh | ||
| drill.sh | ||
| install-lifecycle.sh | ||
| release.sh | ||