fix: cancel_invocation auto-escalates when graceful cancel isn't enough

[gregmagolan]

Summary

cancel_invocation() now automatically escalates when a graceful cancel isn't enough to stop a Bazel build.

How it works

cancel_invocation() sends the 1st SIGINT to the Bazel client (graceful cancel) and returns a Cancellation object. When wait() is called, if the build hasn't stopped within force_kill_after_ms (default 5000ms), it escalates following Bazel's 3-SIGINT protocol:

Step	Signal	Bazel behavior
cancel_invocation()	1st SIGINT	CancelRequest RPC — stop scheduling new actions
force() / auto-escalation	2nd SIGINT	Repeated CancelRequest (server already cancelling)
force() / auto-escalation	3rd SIGINT	Bazel's built-in KillServerProcess — server SIGKILL'd, client exits
Last resort (after 5s)	SIGKILL	We SIGKILL both client and server ourselves

If the client has already crashed, falls back to SIGKILL on the server daemon directly (PID read from <output_base>/server/server.pid.txt). If the server isn't busy, force() is a no-op.

AXL examples

Default — auto-escalates after 5s:

cancellation = ctx.bazel.cancel_invocation()
cancellation.wait()

Custom grace period:

cancellation = ctx.bazel.cancel_invocation(force_kill_after_ms = 10000)
cancellation.wait()

Manual control:

cancellation = ctx.bazel.cancel_invocation(force_kill_after_ms = 0)
if not cancellation.wait(timeout_ms = 5000):
    cancellation.force()

Safety rails

• wait(timeout_ms=N) with force_kill_after_ms > 0 → error (ambiguous — pick one mode)
• wait() with force_kill_after_ms = 0 and no timeout_ms → error (would hang forever)

Changes

• cancel.rs: wait() supports timeout_ms and auto-escalation. force() sends 2nd + 3rd SIGINT (Bazel's 3-stage protocol), monitors client PID, falls back to SIGKILL. Guards against killing an idle server.
• mod.rs: cancel_invocation accepts force_kill_after_ms param.
• info.rs: Added server_pid_nonblocking() (reads PID from disk via output_base). Capture stderr from bazel info for diagnostics.
• axl.axl: New test cases for force-cancel, auto-escalation on a slow build, repeated cancel calls, and stale cancellation objects.
• examples/slow_build/: Test fixture with a 30s sleep genrule for cancel tests.

Test plan

• Rust unit tests for validate_wait_params — all 4 combinations of timeout_ms/force_kill_after_ms
• AXL integration tests:
  • Test 6: cancel_invocation() with bad startup flags
  • Test 7: Manual force() on a running build
  • Test 8: Auto-escalation on a sleep 30 build with force_kill_after_ms=1000
  • Test 9: wait(timeout_ms) on non-busy server returns True
  • Test 10: Three cancel_invocation() calls in a row (discarded results)
  • Test 11: busy/wait()/force() on a stale Cancellation from a finished build

🤖 Generated with Claude Code

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 57d9545d3a

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".