Update retry docs with catch details
#2212
Assignees
Comments
Open
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
Prerequisite: #2190
The text was updated successfully, but these errors were encountered: