Skip to content

test(agent): loosen flaky async-timeout deadlines to survive loaded CI#4773

Open
logicwu0 wants to merge 1 commit into
alibaba:mainfrom
logicwu0:test/stabilize-flaky-async-timeouts
Open

test(agent): loosen flaky async-timeout deadlines to survive loaded CI#4773
logicwu0 wants to merge 1 commit into
alibaba:mainfrom
logicwu0:test/stabilize-flaky-async-timeouts

Conversation

@logicwu0

@logicwu0 logicwu0 commented Jul 3, 2026

Copy link
Copy Markdown
Contributor

Two async tests fail intermittently on CI (the test job), turning the check red on unrelated PRs even though the behavior under test is correct and they pass locally:

  • AgentToolNodeAsyncExecutionTest.StateUpdateOnTimeoutTests.stateUpdates_shouldBeCleared_onTimeoutWithCancellableTool
  • CancellableAsyncToolCallbackTest.TimeoutScenarioTests.tool_shouldStopGracefully_whenCheckingCancellation

Root cause

Both tests wait on a CountDownLatch that is counted down by a task submitted to CompletableFuture.supplyAsync(...) — i.e. the shared ForkJoinPool.commonPool(). On GitHub-hosted runners the common pool has very low parallelism, and under parallel test execution its start/scheduling latency can spike past the hard-coded 5s / 1s await deadlines. The latch is then not observed in time and assertTrue(latch.await(...)) fails.

A previous attempt already bumped one knob (// Increased from 100ms for CI stability / 1s to 5s), which reduced but did not eliminate the flakiness.

Fix

Raise the two await(...) deadlines to 30s. These deadlines are only upper bounds: a successful run returns the instant the latch fires and never waits the full duration, so a larger value has no effect on green runs — it only tolerates scheduling spikes before declaring failure. No assertion is weakened (the correctness checks — stateUpdates.isEmpty(), token.isCancelled(), iterationsCompleted < 100 — are unchanged).

Local run: both classes green (Tests run: 29, Failures: 0); spotless:apply run.

stateUpdates_shouldBeCleared_onTimeoutWithCancellableTool and
tool_shouldStopGracefully_whenCheckingCancellation both wait on a CountDownLatch
that a task running on ForkJoinPool.commonPool() counts down. Under parallel test
execution on a loaded CI runner, the task's start/scheduling latency can exceed the
hard 5s/1s await deadlines, so the latch is not observed in time and the test fails
even though the behavior under test is correct (these pass locally).

The await() deadlines are only upper bounds: a successful run returns the instant
the latch fires and never waits the full duration. Raise them to 30s so scheduling
spikes no longer cause spurious failures, without weakening any assertion.
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