Validate activity task stamps before reuse

[yiminc]

Summary

• add the activity task stamp to IsActivityTaskValidRequest and generated API stubs
• require history's activity validation logic to match the stored stamp
• plumb the stamp from matching task validation and cover the new behavior with tests
• increment activity stamps for each retry attempt and extend tests for paused retries

Testing

• GOTOOLCHAIN=local go test -tags test_dep ./service/history/workflow -run TestRetryActivity (fails: go.mod requires go >= 1.25.0 and local toolchain is go1.24.3)

---

https://chatgpt.com/codex/tasks/task_b_68faffae045c832c9d8220bcbe50bac7

[bergundy]

Won't this fail for existing activity tasks that were generated without a stamp?

[yiminc]

Stamp was added to AI the same time they were added to the matching tasks. For tasks before that, the Stamp from AI would be 0 and same for the tasks. But I could add a defensive check to enforce only when both stamp are > 0.

[bergundy]

Ah okay, so this should be fine.

[yiminc]

we decided to revert this because the additional check will cause the first task always be valid and that could cause head-of-queue blocking issue on standby side.

[bergundy]

The way that this is implemented feels error prone to me. It's too easy to mutate the activity and forget to update the stamp. I skimmed the locations where the activity is updated in the code and I think we may have some edge cases that are not covered (need to double check). I would consider updating the stamp in MutableStateImpl.UpdateActivity for any field change that warrants updating it.

[yiminc]

The way that this is implemented feels error prone to me. It's too easy to mutate the activity and forget to update the stamp. I skimmed the locations where the activity is updated in the code and I think we may have some edge cases that are not covered (need to double check). I would consider updating the stamp in MutableStateImpl.UpdateActivity for any field change that warrants updating it.

The purpose of this validation is to avoid building up backlog with invalid tasks. There isn't much of negative consequence to mis-update the stamp for any update to activity, as long as the most common case of retry has the stamp updated that would serve the purpose. But if there is better way of doing this, we could improve later.

[bergundy]

The way that this is implemented feels error prone to me. It's too easy to mutate the activity and forget to update the stamp. I skimmed the locations where the activity is updated in the code and I think we may have some edge cases that are not covered (need to double check). I would consider updating the stamp in MutableStateImpl.UpdateActivity for any field change that warrants updating it.

The purpose of this validation is to avoid building up backlog with invalid tasks. There isn't much of negative consequence to mis-update the stamp for any update to activity, as long as the most common case of retry has the stamp updated that would serve the purpose. But if there is better way of doing this, we could improve later.

We should do better for when we port this to CHASM.