Remove build id from sticky recordWorkflowTaskStarted #6096
Conversation
| @@ -283,7 +283,12 @@ func (pm *taskQueuePartitionManagerImpl) PollTask( | |||
| if pm.partition.Kind() == enumspb.TASK_QUEUE_KIND_STICKY { | |||
| // In the sticky case we always use the unversioned queue | |||
| // For the old API, we may kick off this worker if there's a newer one. | |||
| versionSetUsed, err = checkVersionForStickyPoll(versioningData, pollMetadata.workerVersionCapabilities) | |||
| err = checkVersionForStickyPoll(versioningData, pollMetadata.workerVersionCapabilities) | |||
| // We set versionSetUsed to true for all sticky tasks until old versioning is cleaned up. | |||
There was a problem hiding this comment.
Overall this approach seems a little hacky. It seems like it would be clearer if we determined "using version sets" based on whether (any) version sets were present in user data. Then this bug would only happen on transition from unversioned to using version sets.
There was a problem hiding this comment.
Honestly not sure which one is more hacky. Regardless of this issue of mixing old and new versioning, one can argue that not populate stamp for sticky queue is a good thing because there is no new information in it. Although I'm not sure we want to do that, for the sake of consistency with other WFT started events.
Maybe if we change the versionSetUsed variable to something like forwardBuildId it'd look less hacky?
Anyway, IMHO a hacky solution is ok in this case as all of this will be deleted soonish.
ShahabT
force-pushed
the
shahab/old-versioning-sticky
branch
from
6f6502a to
e1382a7
Compare
|
I closed the other PR and reduced the changes in this PR to only include the part that we want to get into 1.24. Once this is merged I'll cherry-pick it in 1.24 branch. |
Just add the label, the person doing the release does the cherry-pick |
What changed?
Why?
How did you test it?
Unit tests will be added.
Potential risks
None.
Documentation
None.
Is hotfix candidate?
No.