Raise error if parsed response is a string#60
Raise error if parsed response is a string#60zacblazic wants to merge 1 commit intoonelogin:masterfrom
Conversation
It's currently possible for the parsed response to be a string instead of a hash in some cases. One scenario is if the server returns a 504 gateway timeout, in which case we are returned a string of HTML instead of JSON response.
|
Hi @zacblazic, sorry for the delayed reply. I believe that rather than taking care of the response with a 504 happens, we should instead detect the 504 status and raise the error then, in fact that was my goal in that ticket that I never implemented: #19. Not sure if this patch could side effect other endpoints returning a string |
|
No worries @pitbulk! I agree that we should ideally be checking the response codes, definitely first prize in this scenario, but I opted for a quick win here instead. 😅
I thought about this and ensured that it would be safe as the code is right now since the code explicitly expects the result to be a hash currently by performing a check for specific keys which would fail otherwise i.e. Anyways, not saying this is a perfect fix but it should work. |
It's currently possible for the parsed response from
fetch_next_pageto be a string instead of a hash.In one scenario, when the server returns a 504 gateway timeout, it will return an HTML string instead of a hash and attempt to call
has_key?on the string:My changes aim to handle this edge case and raise an exception with the underlying HTTP response message and code: