Fix TestWorkflowTaskRedirectInRetryFirstTask flake #6189
Conversation
…n, instead of always calling before
…stWorkflowTaskRedirectInRetryFirstTask-flake
| @@ -5022,6 +5024,13 @@ func (s *VersioningIntegSuite) waitForWorkflowBuildId( | |||
| ) | |||
| } | |||
|
|
|||
| // validateWorkflowBuildIds gets the specified workflow execution from visibility and validates that the BuildIds | |||
There was a problem hiding this comment.
I don't think DescribeWorkflowExecution make visibility calls. it loads the execution, including its SAs, from the DB. so this comment is not accurate.
| // - expectedBuildId: the currently-assigned build id for the workflow execution (only present in newVersioning) | ||
| // - expectedStampBuildId: the most recent version of a worker that processed a task for that workflow execution | ||
| // | ||
| // If expectedBuildId != "" and newVersioning == true, waitForWorkflowBuildId should be called before this to prevent |
There was a problem hiding this comment.
The reason I'm calling this waitForWorkflowBuildId in firstWorkflowTaskAssignmentSpooled is that I'm checking wf build ID before the task is dispatched (when worker is not running). That relies on the history task processing timing because MS build ID is updated after the transfer task is sent to Matching and it is backlogged.
MS build ID is also updated when the task is dispatched (when record*TaskStarted is called). So in tests that wait for task dispatch via other means like waiting for the timedoutTask channel for example, calling waitForWorkflowBuildId should not add any value. Still I see I called it in firstWorkflowTaskAssignmentSyncMatch and testWorkflowTaskRedirectInRetry that already are waiting for channels. Not sure if I had a reason or it was a mistake. Wish I had put a note there.
What changed?
v1.1to land in visibility before validating entire build id search attribute structure (this solves the observed flake)v1.2before validating it (not sure if this would flake, but it could)Why?
Here's a run with the latest flake: https://github.com/temporalio/temporal/actions/runs/9575636250/job/26400905169
We need to make sure that the build ID search attribute has enough time to update before we validate all the parts of it.
How did you test it?
Tested locally, testing in CI now
Potential risks
None
Documentation
Commented function
Is hotfix candidate?
No