-
Notifications
You must be signed in to change notification settings - Fork 196
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
Catch down network exception and non-object responses in fetch #2492
Conversation
I guess the overall cause here is inconsistent return values coming from guzzle? |
I'm not sure on this, my suspicion is that the API is returning something like a plaintext 503 instead of JSON, but I can't reproduce so I can't prove that. I think once we start displaying the actual returned values as an error we'll be closer to knowing what's going on in this case. |
I'd characterize it as.. "terminus currently assumes it will receive valid responses and unceremoniously crashes if its expectations aren't met. this PR checks the assumptions and deliberately return its own error when unexpected values are received, rather than letting the PHP runtime deal with it" |
Alright here it is using
|
4f6a86c
to
7857a37
Compare
@greg-1-anderson when you have a chance to review, thank you |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's polish this a bit, doesn't look ready to go to customers yet.
Alright cleaned up a bit further. Made variable names more clear, double checked the error logging. |
Catching of exceptions arising from two states.
1) Network is completely down.
This would previously give an uncaught exception when doing any operation from Terminus.
That is now caught and handled
2) Invalid network responses.
This I couldn't reproduce, but based on a stack trace found that certain API responses would sometimes come back processed as a string rather than an object while monitoring workflow logs.
Previous uncaught fatal exception:
Since I wasn't able to reproduce this, I added a handler for it to give more details of the error and a clearer failure.