-
Notifications
You must be signed in to change notification settings - Fork 3
Open
Labels
bugSomething isn't workingSomething isn't working
Description
Error objects which use catch_exception statements, only actually catch the
exception if it is set as a potential_error on a Endpoint.
Within a LookupArgumentSet that specify potential_error, no errors defined by
catch_exception raised within the LookupArgumentSet resolver are caught.
Below is a rough example of the issue:
class Book < Rapid::Object
field :id, :string
field :name, :string
end
class TimeoutError < Rapid::Error
code :timeout_error
catch_exception Faraday::TimeoutError
end
class BookLookup < Rapid::LookupArgumentSet
name 'Book Lookup'
argument :id, :string
potential_error TimeoutError
resolver do |set, request, service|
Faraday.get("http://foo/bar/#{set[:id]}").parsed_body
end
end
class BookGet < Rapid::Endpoint
name 'Get book info'
argument :book, BookLookup, required: true
field :book, Book
def call
book = request.arguments[:book].resolve
response.add_field :book, book
end
endIf the BookLookup resolver raises a Faraday::Timeout error, it is not captured
and Rapid returns a unhandled_exception error code instead of the custom
timeout_error.
Adding potential_error TimeoutError on the Endpoint itself fixes the issue,
but obviously it would be better if the LookupArgumentSet resolver captured all
errors relevant to the LookupArgumentSet.
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
bugSomething isn't workingSomething isn't working