Repository navigation
test: wait on each stall checkpoint's own effect in wake-queue tests - #34
Merged
Merged
Conversation
… wake Round one of the development-branch task (ask for the branch, store it in the repo as .firstmate-base, keep fleet sync on it) already landed on main as #1; this carries its one open thread. The foreign-queue stall cases in tests/fm-wake-queue.test.sh failed under load. Their quiet steps ran fm-watch-checkpoint.sh for one second, and on a loaded runner the watcher is killed before it reaches its stall observation, so the step silently records nothing. The alert step then starts the no-progress interval at its own frozen fake instant, so it can never alert; retrying only wakes on check: rearm-resurface for the previous checkpoint's exit, which is why a longer ceiling could not help. checkpoint_until now runs each step until its observable effect lands: a quiet step until the watcher has recorded that step's observation, an alert step until the alert is published. Each round's bound grows by a second, and the checkpoint exits on the first wake, so a healthy run pays nothing extra.
…figuration only. In `.github/workflows/ci.yml`, both Pi install steps (the portable parallel job and the portable serial job) now run `npm install -g @earendil-works/pi-coding-agent@0.87.1`. That is the last version main's CI was green on. Next to each install is a comment saying the pin is a hold against an upstream Pi 0.99.x break published 2026-09-30, not a fix for it, and should be lifted once the extension works with Pi 0.99.x. I did not touch the extension code or the failing tests (`fm-calm-pi-extension`, `fm-pi-branch-extension`), and nothing else is unpinned. Checks: the workflow file loads as valid YAML in Python, and `npm view` confirms version 0.87.1 exists on npm. I could not run `tests/fm-ci-workflow.test.sh` locally because it needs Ruby, which is not installed here. Before this, the existing Pi extension tests were not run against 0.87.1. For the PR body, whoever owns that phase must state plainly that the Pi pin is a hold against an upstream break published the same day, not a fix for it. On ci-3: Behavior portable serial 1 was cancelled, which is a missing result, not a pass. The new push re-runs it, and its real verdict must be the one taken
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
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.
Intent
The captain's ruling, 2026-09-10, in his words: "for every repo we are working on you should ask captain what is the main development branch and store that value in the repo and every time merge or get worktree against that branch."
This is round two of that task. Round one's agent was lost when its terminal disappeared, but all of its work survives.
You are changing firstmate's own shared tracked material, so load the
firstmate-coding-guidelinesskill before editing anything and follow it: one sentence per line, plain dashes, shellcheck-clean scripts, colocated tests, and never an agent as a commit co-author.Write tests and RUN them. This is firstmate's own tooling and its tests are fast.
Never
cdas a separate step before a read command - pass the path or usegit -C <dir>. Compact your context before 40%.What Changed
wait_for_checkpoint_alertand the fixed--seconds 1/FM_TEST_ALERT_CEILINGcheckpoint runs intests/fm-wake-queue.test.shwith a newcheckpoint_untilhelper. It rerunsfm-watch-checkpoint.shwith a bound that grows by one second each round, up toFM_TEST_CHECKPOINT_ROUNDSrounds (12 by default), and stops as soon as the step's effect shows up.observedandpublished. Withobserved, each quiet step now waits until the watcher has written its.secondmate-wake-progress-<mate>record for that fake instant and oldest row. Before this change, a watcher killed early on a loaded runner skipped that record without any error.published, alert steps wait for their alert line to appear. Quiet steps now fail loudly if the watcher never records its observation. This covers both the foreign-queue stall case and the reprovisioned-generation case.Pi package pin in CI (a hold, not a fix)
.github/workflows/ci.ymlnow installs@earendil-works/pi-coding-agent@0.87.1in both Pi install steps instead of the unpinned latest.tests/fm-calm-pi-extension.test.shandtests/fm-pi-branch-extension.test.sh, which this pull request does not touch.🤖 Generated with Claude Code
Risk Assessment
✅ Low: The change only touches tests: it replaces fixed-duration checkpoint steps with retries that stop once each step's own recorded effect appears. That is sound because the stall tick runs before the rearm-resurface wake in the watcher loop, and a retried alert step is deduplicated by the queued-key and receipt checks.
Testing
I ran the changed wake-queue test file in full (all cases pass). I then ran its two foreign-queue stall tests three times under heavy CPU load: all passed at the target commit, and the base commit failed all three runs. That reproduces the flake the change fixes: 'no actionable wake within 60s' and 'check: rearm-resurface'. The round-one test for the recorded base branch also passes. Logs are in the evidence directory. Temporary scripts and load processes were removed, and the worktree is clean.
Evidence: Target commit: stall tests under CPU load (3/3 pass)
Source: Target commit: stall tests under CPU load (3/3 pass)
Evidence: Base commit: stall tests under CPU load (3/3 fail, reproduces flake)
Source: Base commit: stall tests under CPU load (3/3 fail, reproduces flake)
Evidence: Full fm-wake-queue test run
Source: Full fm-wake-queue test run
Evidence: Base-branch spawn test run
Source: Base-branch spawn test run
Pipeline
Updates from git push no-mistakes
✅ **intent** - passed
✅ No issues found.
✅ **Rebase** - passed
✅ No issues found.
✅ **Review** - passed
✅ No issues found.
✅ **Test** - passed
✅ No issues found.
bash tests/fm-wake-queue.test.sh(full file, idle machine): all 42 cases ok, including the two stall casesOnly the two stall tests (test_secondmate_foreign_queue_stall_tracks_progress_and_alerts_once,test_secondmate_reprovisioned_queue_starts_a_fresh_interval) at the target commit, 3 rounds with 3x nproc busy loops saturating the CPUThe same two tests at base commit f84f2f35, 3 rounds under the same load (regression reproduction)bash tests/fm-spawn-base-branch.test.sh(round-one behaviour: the worker starts from the project's recorded base branch)✅ **Document** - passed
✅ No issues found.
✅ **Lint** - passed
✅ No issues found.
✅ **Push** - passed
✅ No issues found.