You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'd like to ask if it would be possible to have a specific error class to signal errors when pulling supergraph schema from uplink.
Right now, when this happens, a generic error is thrown, and if we want to catch those errors, we need to match the error message, which seems a bit brittle (I wouldn't be surprised if that message is changed in the future).
Would it be possible to extend the Error class with a more specific name (something like UplinkFetchError), and export it, so we can check the name of that error instead of the message?
A bit of context, we plan on catching these errors on our Gateways. If Apollo Uplink is down, we can at least rescue from those errors and use a local schema instead, so our Gateways can still start up, even if the schema is an old one.
Thank you!
The text was updated successfully, but these errors were encountered:
Absolutely, we'd love to have you take a crack at it if you'd like! We did place this on a team's backlog but would love your contribution if you're able to give the time.
nogates
added a commit
to nogates/federation
that referenced
this issue
Feb 3, 2022
Hello there!
I'd like to ask if it would be possible to have a specific error class to signal errors when pulling supergraph schema from uplink.
Right now, when this happens, a generic error is thrown, and if we want to catch those errors, we need to match the error message, which seems a bit brittle (I wouldn't be surprised if that message is changed in the future).
Would it be possible to extend the Error class with a more specific name (something like
UplinkFetchError
), and export it, so we can check the name of that error instead of the message?A bit of context, we plan on catching these errors on our Gateways. If Apollo Uplink is down, we can at least rescue from those errors and use a local schema instead, so our Gateways can still start up, even if the schema is an old one.
Thank you!
The text was updated successfully, but these errors were encountered: