mirror of
https://github.com/hanzoai/tasks.git
synced 2026-10-30 14:56:19 +00:00
Michael SnowdenandGitHub
e3aebc4edd
<!-- Describe what has changed in this PR --> **What changed?** This PR makes us use the shard ID of the task in the original cluster instead of the shard ID in the current cluster when merging DLQ'd replication tasks (or writing any task to the DLQ actually). <!-- Tell your future self why have you made these changes --> **Why?** The number of shards between any two clusters for a given namespace don't have to be the same. One has to be a multiple of the other, though. However, I noticed a bug when using our local xdc config with cluster-a and cluster-b: ``` "Error": "AddTasks failed while re-enqueuing tasks to shard 9 (type: dlq-error-type-invalid-request, retryable: false): Task is for wrong shard: index = 0, task shard = 25, request shard = 9", ``` This error was caused by the fact that the task in question has a different computed shard ID in cluster-b, where there are only 16 shards, than it does in cluster-a, where there are 32 shards. <img width="740" alt="Untitled" src="https://github.com/temporalio/temporal/assets/5942963/ac9c2754-acfc-44ae-bb8d-a98f9ecd6b4d"> Fortunately, the V2 replication DLQ hasn't even been turned on anywhere yet, so this didn't cause any issues. It was caught as part of testing before rollout. <!-- How have you verified this change? Tested locally? Added a unit test? Checked in staging env? --> **How did you test it?** I wrote some unit tests, and I also re-ran the manual test I was doing. I even generated a significant amount of load with `maru`, forced 10s of thousands of replication tasks to fail, and successfully merged all of them. <!-- Assuming the worst case, what can be broken when deploying this change to production? --> **Potential risks** <!-- Is this PR a hotfix candidate or require that a notification be sent to the broader community? (Yes/No) --> **Is hotfix candidate?**