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
Allowing catch
to work with any
request types
#2213
Comments
Open
I think allowing |
decision: Allow Any or exact match, add request type ref |
matt2e
changed the title
Consider allowing
Allowing Aug 6, 2024
catch
to work with non-exact request typescatch
to work with any
request types
github-merge-queue bot
pushed a commit
that referenced
this issue
Aug 19, 2024
closes #2213 `builtin.CatchRequest` now has the following features: - the associated request type can be `any` to allow for catching multiple verbs with different request types - The request will be unmarshalled to primitives (like string, int, map, array etc) rather than ftl structs - Includes the verb that failed as a `builtin.Ref`, which is a data type with `module` and `name` strings - Includes the request type as a string, eg: `example.Input`, `String`, etc - Originally I had this as a `builtin.Ref` but that doesnt work for non-ref types There is certainly room for improvement in terms of how we want to expose these schema definitions, but this PR doesn't try go too far down that road.
safeer
pushed a commit
that referenced
this issue
Aug 19, 2024
closes #2213 `builtin.CatchRequest` now has the following features: - the associated request type can be `any` to allow for catching multiple verbs with different request types - The request will be unmarshalled to primitives (like string, int, map, array etc) rather than ftl structs - Includes the verb that failed as a `builtin.Ref`, which is a data type with `module` and `name` strings - Includes the request type as a string, eg: `example.Input`, `String`, etc - Originally I had this as a `builtin.Ref` but that doesnt work for non-ref types There is certainly room for improvement in terms of how we want to expose these schema definitions, but this PR doesn't try go too far down that road.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Currently when declaring a retry with a catch, the catch verb must include the exact request type. eg:
This prevents these use cases:
It could be useful to have a catch verb with takes
builtin.CatchRequest[map[string]Any]
or justbuiltin.CatchRequest[Any]
.Something to be careful about:
The text was updated successfully, but these errors were encountered: