Provide flag to tell the update handler that the handling is from a re-apply

[longquanzheng]

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

In non-reset case, we will have a short or no activity retry, so that the error would return to the caller/client early.
However, on a retry with re-apply, we need to ensure the activity will not fail, because the update has been considered completed (just like signal has been accepted) from the client.

Right now this is not possible.

Kinda related to temporalio/temporal#5873
If the workflowContext can tell that the workflowTask is from a reset, that's probably enough?

Describe the solution you'd like
A clear and concise description of what you want to happen.
SDK should know this info (the update is from Admitted event), just provide a flag to us.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
NA

Additional context
Add any other context or screenshots about the feature request here.

[Quinn-With-Two-Ns]

Transferring to features since this is not specific to the Go SDK

[Quinn-With-Two-Ns]

To clarify, do you want to know if the update request came being reapplied from a reset? Since temporalio/temporal#5873 refers to a workflow task, but updates can span multiple workflow tasks.

[longquanzheng]

if the update request came being reapplied from a reset?

Yes, that's right.

Since temporalio/temporal#5873 refers to a workflow task, but updates can span multiple workflow tasks.

That's true. So that workflow context is less ideal. But should be enough if I write the code carefully (passing the flag to later handling logic) 😂

[dandavison]

• Go: Provide flag to tell the update handler that the handling is from a re-apply sdk-go#1776