generated from TBD54566975/tbd-project-template
-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Need a mechanism to handle asynchronous call failures (pubsub, cron, FSM, etc.) #2185
Comments
Open
How come? |
Plan:
Future plans:
|
Removing P0, Moe said they won't have time to use it this week |
github-merge-queue bot
pushed a commit
that referenced
this issue
Aug 8, 2024
closes #2185 closes #2212 Retry directives can now define a catch verb: ```go //ftl:retry 10 1s catch example.catchPayments ``` Catch verbs have a special request type: ```go func CatchPayments(ctx context.Context, req builtin.CatchRequest[publisher.PubSubEvent]) error { // do something return nil } ``` Behavior: - FTL will keep attemping the catch verb until it does not return an error. It will do this at the backoff rate that the retries progressed to before catching. - `builtin.CatchRequest[EventType]` provides the original request and a string of the error that was returned on the last attempt by the subscriber - Once in a catch verb for a FSM transition, there is currently no way to prevent the FSM from reaching a failed state Behind the scenes: Async calls use a new row per attempt. This PR continues that pattern: - After the last attempt is completed, if there is a catching verb defined then a new row is added with `catching = true` - Originally I had gone down the road of making this a different state but it got tricky with `AcquireAsyncCall` coordinating leases with the `pending` and `executing` states, and would require 2 new states for the catching equivalent of those. - If the catch verb could not be called or fails, a new async call row is inserted with the current backoff - The next scheduled attempt to catch keeps the original verb's error, not the new catch error
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Ideally a single mechanism that can be applied to all of them, rather than specific solutions for each such as a dead letter topics for pubsub.
Possible ideas:
ftl.LastRetry(ctx)
function that can be used to detect if the current retry is the last one.//ftl:retry
to support a "catch" verb that will be called on complete failure.The text was updated successfully, but these errors were encountered: