test: harden pre-existing load-sensitive e2e flakes surfaced under parallel load

These tests are byte-identical to main and are not regressions from this
PR; a 15x parallel stability run starved the CI runners enough to trip
their tight async-state timeouts:

- DynamicForkTests two-sequential-fork completion: 10s -> 60s (fork1 ->
  join1 -> fork2 -> join2 progression exceeds 10s under load).
- DynamicForkTests testCorrectTaskIdOnRetries: assert the 3-attempt count
  INSIDE the FAILED await (the final retry's task record can lag the
  workflow FAILED status), instead of in a follow-up read.
- SubWorkflowInlineTests: SUB_WORKFLOW task SCHEDULED->IN_PROGRESS and
  completion awaits 10s/3s -> 30s.
- WorkflowRerunTests multi-rerun-cycle setup: subWorkflowId await 10s -> 30s.

All are positive 'eventually reaches X' waits, so raising the ceiling is
free on passing runs and only adds headroom under load.
This commit is contained in:
Manan Bhatt
2026-07-04 01:02:11 +05:30
parent dbf98be9ff
commit 555d7d069f
3 changed files with 22 additions and 9 deletions
@@ -503,7 +503,10 @@ public class DynamicForkTests {
startWorkflowRequest.setWorkflowDef(workflowDef);
String workflowId = workflowAdminClient.startWorkflow(startWorkflowRequest);
await().atMost(10, TimeUnit.SECONDS)
// Two sequential dynamic forks: fork1 -> join1 -> fork2 -> join2. Each poll completes
// whatever is currently SCHEDULED; the async fork/join progression can exceed 10s under
// CI load, so allow a generous ceiling (returns as soon as COMPLETED holds).
await().atMost(60, TimeUnit.SECONDS)
.pollInterval(500, TimeUnit.MILLISECONDS)
.untilAsserted(
() -> {
@@ -566,8 +569,19 @@ public class DynamicForkTests {
.pollInterval(2, TimeUnit.SECONDS)
.untilAsserted(
() -> {
var wf = workflowAdminClient.getWorkflow(workflowId, false);
var wf = workflowAdminClient.getWorkflow(workflowId, true);
assertEquals(Workflow.WorkflowStatus.FAILED, wf.getStatus());
// All 3 attempts (original + 2 retries) must be present. The final
// retry's task record can lag the workflow FAILED status under load,
// so assert the count inside the await rather than in a follow-up read.
var attempts =
wf.getTasks().stream()
.filter(
it ->
"fail_on_purpose"
.equals(it.getTaskDefName()))
.toList();
assertEquals(3, attempts.size());
});
var workflow = workflowAdminClient.getWorkflow(workflowId, true);
@@ -576,8 +590,6 @@ public class DynamicForkTests {
.filter(it -> "fail_on_purpose".equals(it.getTaskDefName()))
.toList();
assertEquals(3, tasks.size());
for (Task t : tasks) {
assertEquals(t.getTaskId(), t.getInputData().get("task_id"));
}
@@ -75,8 +75,8 @@ public class SubWorkflowInlineTests {
taskResult.setTaskId(taskId);
taskClient.updateTask(taskResult);
// Workflow will be still running state
await().atMost(10, TimeUnit.SECONDS)
// Workflow will be still running state (SUB_WORKFLOW task SCHEDULED->IN_PROGRESS is async)
await().atMost(30, TimeUnit.SECONDS)
.untilAsserted(
() -> {
Workflow workflow1 = workflowClient.getWorkflow(workflowId, true);
@@ -99,7 +99,7 @@ public class SubWorkflowInlineTests {
taskClient.updateTask(taskResult);
// Wait for workflow to get completed
await().atMost(3, TimeUnit.SECONDS)
await().atMost(30, TimeUnit.SECONDS)
.untilAsserted(
() -> {
Workflow workflow1 = workflowClient.getWorkflow(workflowId, true);
@@ -3536,8 +3536,9 @@ public class WorkflowRerunTests {
startRequest.setVersion(1);
String workflowId = workflowClient.startWorkflow(startRequest);
// Wait for subworkflow to be created with its inner task
await().atMost(10, TimeUnit.SECONDS)
// Wait for subworkflow to be created with its inner task (async decide can lag under
// load)
await().atMost(30, TimeUnit.SECONDS)
.untilAsserted(
() -> {
Workflow wf = workflowClient.getWorkflow(workflowId, true);