Skip to content

Deflake TestWorkflowEngine_ParallelExecution - #6112

Merged
ChrisJBurns merged 1 commit into
mainfrom
deflake-workflow-parallel-execution
Jul 28, 2026
Merged

Deflake TestWorkflowEngine_ParallelExecution#6112
ChrisJBurns merged 1 commit into
mainfrom
deflake-workflow-parallel-execution

Conversation

@ChrisJBurns

Copy link
Copy Markdown
Collaborator

Summary

TestWorkflowEngine_ParallelExecution failed the unit-test job on main (e.g. commit 2858ac8c3) with:

workflow_engine_test.go:531: "1" is not greater than or equal to "2"
Messages: at least 2 steps should run concurrently

Why: The test proves the two independent level-1 steps run in parallel by asserting maxConcurrent >= 2. That counter only reaches 2 if the two 50ms mock sleeps overlap in wall-clock time. On a loaded CI runner the second goroutine can be starved and start only after the first has already finished its sleep, leaving maxConcurrent == 1 — so the test fails regardless of the change under test. The failure is unrelated to the commit it landed on (that PR does not touch pkg/vmcp/composer). This test was previously "deflaked" in #4333, which reduced but did not remove the timing dependence.

What: Replaces the sleeps with a rendezvous barrier — each fetch step blocks on entry until both have arrived, so neither can complete until the other has started. The concurrency assertion is now deterministic under any scheduler load. As a bonus, a genuine regression to sequential execution now surfaces as a clear timeout failure instead of a lucky pass. The engine already runs level steps in parallel via errgroup + a size-10 semaphore, so a barrier of 2 is always satisfiable.

Type of change

  • Bug fix (non-breaking change which fixes an issue)

Test plan

  • Ran go test ./pkg/vmcp/composer/ -run TestWorkflowEngine_ParallelExecution -race -count=30 — all pass, no races.
  • Ran the full pkg/vmcp/composer package with -race — green.

Does this introduce a user-facing change?

No.

Generated with Claude Code

The test asserted maxConcurrent >= 2 to prove the two independent
level-1 steps run in parallel, but that counter only reaches 2 when the
two 50ms mock sleeps overlap in wall-clock time. On a loaded CI runner
the second goroutine can be starved and start only after the first
already finished, leaving maxConcurrent at 1 and failing the test
regardless of the diff under test. This flaked the unit-test job on
main (previously "deflaked" in #4333, which only reduced but did not
remove the timing dependence).

Replace the sleeps with a rendezvous barrier: each fetch step blocks on
entry until both have arrived, so neither can complete until the other
has started. This makes the concurrency assertion deterministic under
any scheduler load, and turns a genuine regression to sequential
execution into a clear timeout failure instead of a lucky pass.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@github-actions github-actions Bot added the size/XS Extra small PR: < 100 lines changed label Jul 28, 2026
@codecov

codecov Bot commented Jul 28, 2026

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 72.42%. Comparing base (9ce78fa) to head (3a55f41).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #6112      +/-   ##
==========================================
- Coverage   72.43%   72.42%   -0.02%     
==========================================
  Files         734      733       -1     
  Lines       75871    75833      -38     
==========================================
- Hits        54960    54924      -36     
+ Misses      17019    17014       -5     
- Partials     3892     3895       +3     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@ChrisJBurns
ChrisJBurns merged commit de0469e into main Jul 28, 2026
48 checks passed
@ChrisJBurns
ChrisJBurns deleted the deflake-workflow-parallel-execution branch July 28, 2026 15:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

size/XS Extra small PR: < 100 lines changed

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants