Skip to content

serve: lame-duck on failed initial fetch, log stale-lock heals; retry Alpine bazel probe - #500

Merged
tinder-maxwellelliott merged 1 commit into
masterfrom
claude/github-action-cron-failures-9efbe5
Sep 14, 2026
Merged

serve: lame-duck on failed initial fetch, log stale-lock heals; retry Alpine bazel probe#500
tinder-maxwellelliott merged 1 commit into
masterfrom
claude/github-action-cron-failures-9efbe5

Conversation

@tinder-maxwellelliott

Copy link
Copy Markdown
Collaborator

Why

Two scheduled workflows are failing:

What changed

src/server.rs

  • A failed initial git fetch no longer exits serve() before the HTTP server binds. New perform_initial_fetch logs the error and leaves the instance lame-ducked: /health and query endpoints return 503, /metrics is still served with ready: false. This restores the RFC RFC: Bazel Query Service #29 behaviour the Kotlin serve had and the README promises.
  • Clearing an orphaned .git/index.lock and retrying the checkout now logs cleared stale git index.lock in <workspace>; retrying checkout of <sha> so the harness (and operators) can see the self-heal path fire.
  • New unit test initial_fetch_failure_lame_ducks_instead_of_exiting covering the un-ready responses and the --noInitialFetch path.

tools/serve_stress_alpine.sh

  • probe_bazel retries up to 4 times with backoff when the probe output matches a download / 5xx / timeout error, and still fails fast on any other error so a genuinely non-working binary falls through to the next flavor quickly.

Verification

  • cargo fmt --check, cargo clippy --all-targets, and the unit tests pass (107 in the lib).
  • Ran the stress harness locally against the patched server: tools/serve_stress.py --quick --only lock and --only lameduck pass every check, including the four that failed in CI (self-heal path logged, startup with remote down -> lame-duck, query against lame-duck instance -> 503, /metrics still served while lame-ducked).
  • The Alpine probe change is shell-only and exercised by the next serve-stress-alpine* cron runs; I could not reproduce the 504 locally.

Reviewer notes

🤖 Generated with Claude Code

… Alpine bazel probe

The Serve Stress cron has been red since 2026-09-10. PR #490 pointed the
stress harness at the Rust //src:bazel-diff serve, and PR #498 then made
it the only implementation, but the Rust port was missing two behaviours
the harness (and README) rely on:

* A failed initial `git fetch` bailed out of serve() before binding, so a
  fresh instance started while the remote is down simply exited. It now
  logs the error and comes up lame-ducked: /health and queries answer 503
  forever, /metrics keeps answering with ready=false, matching the RFC #29
  contract the Kotlin serve implemented.
* Clearing an orphaned .git/index.lock and retrying the checkout was
  silent; it now logs "cleared stale git index.lock ..." so the harness
  can count self-heals.

Separately, the Alpine real-repo cron failed on 2026-09-14 because the
bazel probe in tools/serve_stress_alpine.sh treated a GitHub Releases 504
(downloading rules_java) as "bazel does not run on musl". The probe now
retries download/5xx failures a few times with backoff and still fails
fast on any other error.

Verified locally: cargo test/clippy/fmt clean, and
`tools/serve_stress.py --quick --only lock` / `--only lameduck` pass all
checks that failed in CI.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
@tinder-maxwellelliott
tinder-maxwellelliott marked this pull request as ready for review September 14, 2026 16:32
@tinder-maxwellelliott
tinder-maxwellelliott merged commit 113105f into master Sep 14, 2026
25 checks passed
@tinder-maxwellelliott
tinder-maxwellelliott deleted the claude/github-action-cron-failures-9efbe5 branch September 14, 2026 17:02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant