Skip to content

fix(integration): stop GetChangedTargets test timing out flakily#219

Open
xytan0056 wants to merge 1 commit into
mainfrom
fix/integration-test-timeout-flake
Open

fix(integration): stop GetChangedTargets test timing out flakily#219
xytan0056 wants to merge 1 commit into
mainfrom
fix/integration-test-timeout-flake

Conversation

@xytan0056

@xytan0056 xytan0056 commented Jul 17, 2026

Copy link
Copy Markdown
Contributor

Problem

TestIntegration_GetChangedTargets flakes with context deadline exceeded (run).

Cause

A Bazel server hang, not slowness — the failing nested query sits at Loading: 0 packages loaded for the full timeout. Workers are pooled and reused; each reuse does a git checkout that swaps the tree under a long-lived Bazel server, intermittently wedging the next query's loading phase. Raising query_timeout only moves the wall.

Fix (test/CI-only)

  • Run the nested query in Bazel --batch mode (fresh server per query, no state across checkouts), via a new RepositoryConfig.BazelStartupOptions knob — defaults empty, no prod change.
  • Raise requestTimeout to 20m (was equal to query_timeout).
  • Persist ~/.cache/bazel-disk-cache across runs.

Verified: local PASSED in 81s; CI Integration Tests green in 6m45s.

@xytan0056
xytan0056 requested review from a team as code owners July 17, 2026 23:56
@xytan0056
xytan0056 force-pushed the fix/integration-test-timeout-flake branch 2 times, most recently from 3f55a0a to a22c2bf Compare July 18, 2026 00:48
The nested `bazel query` intermittently wedged during Bazel's loading phase
("Loading: 0 packages loaded" until the timeout fired), which surfaced as
"context deadline exceeded". It was a hang, not slowness: workers are pooled and
reused across requests, and each reuse does a `git checkout` that swaps the
source tree out from under a long-lived Bazel server still watching it, which
can deadlock the next query's loading phase. Raising timeouts only moves the
wall — the second GetChangedTargets subtest reliably hit it.

- Run the nested query in Bazel batch mode (--batch) in the integration test,
  via a new config.RepositoryConfig.BazelStartupOptions knob plumbed through the
  native graph runner as Bazel startup flags. Batch mode spawns a fresh,
  short-lived Bazel per query, so no server state persists across checkouts and
  there is nothing to wedge. Verified locally: integration_test PASSED in 81s.
- Raise requestTimeout to 20m (was equal to query_timeout at 10m, leaving zero
  headroom) and keep query_timeout at 600s as a generous per-query bound.
- Persist Bazel's disk cache (.bazelrc --disk_cache) across CI runs to speed the
  outer build.
@xytan0056
xytan0056 force-pushed the fix/integration-test-timeout-flake branch from a22c2bf to ebf9656 Compare July 18, 2026 00:59
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.

2 participants