temporalio / temporalio/temporal
Address force completion when make a request through CompleteByID with a failure.
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 23.2k
- Forks
- 1.9k
- Avg merge
- 2d 8h
- Merged PRs (30d)
- 228
Description
Is your feature request related to a problem? Please describe.
This is a follow-up feature of this issue.
For an async call, the activity may fail due to a bug or design drawback after a call to an external server. However, temporal server may receive a request from CompleteByID API by other servers while the new attempt for a retryable error of the activity is not started yet. In this case, if the request is to complete the activity, we would complete the activity even the new attempt has not started yet so that we can unblock the workflow (refer this PR). However, if the request is to fail the activity, we may think an appropriate way to handle such cases as we are not sure the failure is to fail the activity or it is a transit error and we want to attempt the activity again.
Describe the solution you'd like
For the request to fail an activity:
- If the request is to force fail an activity, we should fail the activity if the attempt for a retryable error has not started yet.
- If the request is to fail an activity due to a non-retryable error, we should fail the activity.
Describe alternatives you've considered
We may introduce a separate API or a flag for a client to tell the server that it would like a request to force fail the activity.
Additional context
Add any other context or screenshots about the feature request here.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reviewing issue #987 and PR #5724, then trace the CompleteByID API handling for activity completion and failure requests. Determine how retryable and non-retryable failures are represented when the next attempt has not started; done means force-fail and non-retryable requests produce the specified activity outcome without incorrectly allowing another attempt.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- backend-api-design, distributed-systems
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 28/100