Skip to content

test(integration): tolerate a slow server in three latency-sensitive suites - #178

Open
ambiorix2099 wants to merge 2 commits into
mainfrom
fix/taskmanager-wait-budget
Open

test(integration): tolerate a slow server in three latency-sensitive suites#178
ambiorix2099 wants to merge 2 commits into
mainfrom
fix/taskmanager-wait-budget

Conversation

@ambiorix2099

Copy link
Copy Markdown

Pull Request type

  • Bugfix
  • Feature
  • Refactoring (no functional changes, no api changes)
  • Build related changes
  • WHOSUSING.md
  • Other (please describe):

Summary

  • Three integration suites fail intermittently against sdkdev with timeouts and empty polls rather than assertion failures: WorkflowExecutor.test.ts (the whole file), LeaseExtension.validation.test.ts and TaskManager.test.ts.
  • Three distinct causes, all budgets too tight to absorb server latency. WorkflowExecutor's beforeAll passed an explicit 30000 that overrode its own describe's jest.setTimeout(300000), and a dead hook fails every test in the file. Both LeaseExtension tests batchPoll with a 200ms long-poll window immediately after startWorkflow, so a queue slower than that yields no task. TaskManager's four waits were the only overrides of waitForWorkflowCompletion's 5-minute default, at 30s.
  • Fix: inherit the describe's timeout, widen the poll window to 5s, raise the four waits to 90s and the file's jest timeout to 120s.

User impact

Shard 3/3 has lost a rotating test since mid-August, on main and on unrelated branches. Once #176 gated REGION_DURABLE, these became the visible failure and took WorkflowExecutor's SYNC cases down with them, since one expired hook fails every test in its file.

Changes

  • WorkflowExecutor.test.ts: drop the beforeAll timeout override so it inherits the describe's 300s.
  • LeaseExtension.validation.test.ts: batchPoll window 200ms to 5s, named POLL_WAIT_MS. The 20s execution and heartbeat behaviour under test is unchanged.
  • TaskManager.test.ts: four waits to 90s via WF_WAIT_MS, jest timeout to 120s, matching WorkerAdvanced.test.ts.

Test plan

  • Cherry-picked onto another branch to exercise CI: every integration v5 sdkdev shard passed on Node 20, 22 and 24, against the same server that had been failing them.
  • Locally against Conductor 3.32.0: TaskManager and LeaseExtension pass, and WorkflowExecutor gets past the hook that was expiring.

These four waits are the only ones in the integration suite that override
waitForWorkflowCompletion's 5-minute default, at 30s. Each waits on a
worker to poll for and complete its tasks, so they are the most sensitive
in the suite to server latency, and they lose races on a contended shared
server: shard 3/3 has intermittently failed on 'multi worker example',
'Should test a workflow' and two WorkerAdvanced cases across Node 20 and
22 since mid-August.

Locally the slowest of them finishes in 3.4s. Raise the budget to 90s and
the file's jest timeout to 120s, matching WorkerAdvanced.test.ts.
… server

WorkflowExecutor.test.ts: the Return Strategy describe sets a 300s jest
timeout, but its beforeAll passed an explicit 30000 override. Registering
several workflow definitions against a slow sdkdev outran it, and a dead
hook fails every test in the file. Inherit the describe's timeout.

LeaseExtension.validation.test.ts: both tests batchPoll with a 200ms
long-poll window immediately after startWorkflow, so a queue that takes
longer than that to surface the task yields no task and the suite fails
on expect(task).toBeDefined(). Widen the window to 5s; the 20s execution
and heartbeat behaviour under test is unchanged.

Verified against a local Conductor: TaskManager and LeaseExtension pass,
and WorkflowExecutor now gets past its hook.
@ambiorix2099

Copy link
Copy Markdown
Author

This CI issue was uncovered while working on this other PR.
I was able to isolate and fix the issue in THIS PR.
The CI is now green and I tested these changes on that other PR, then reverted the changes there and ported them here.
This fix should unblock other PRs.

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