JSONDecodeError: [Errno Expecting value] <html><body><h1>504 Gateway Time-out</h1>
We should add some error handling for the sixteen_zero_four function in views.py. Instead of the page 500'ing.
https://sentry.is.canonical.com/canonical/ubuntu-com/issues/24051/?referrer=github_plugin
JSONDecodeError: Expecting value: line 1 column 1 (char 0)
File "requests/models.py", line 910, in json
return complexjson.loads(self.text, **kwargs)
File "json/__init__.py", line 357, in loads
return _default_decoder.decode(s)
File "json/decoder.py", line 337, in decode
obj, end = self.raw_decode(s, idx=_w(s, 0).end())
File "json/decoder.py", line 355, in raw_decode
raise JSONDecodeError("Expecting value", s, err.value) from None
JSONDecodeError: [Errno Expecting value] <html><body><h1>504 Gateway Time-out</h1>
The server didn't respond in time.
</body></html>
: 0
(3 additional frame(s) were not displayed)
...
File "flask/_compat.py", line 39, in reraise
raise value
File "flask/app.py", line 1950, in full_dispatch_request
rv = self.dispatch_request()
File "flask/app.py", line 1936, in dispatch_request
return self.view_functions[rule.endpoint](**req.view_args)
File "webapp/views.py", line 115, in sixteen_zero_four
total_cves_issued = response.json().get("total_results")
File "requests/models.py", line 917, in json
raise RequestsJSONDecodeError(e.msg, e.doc, e.pos)
JSONDecodeError: [Errno Expecting value] <html><body><h1>504 Gateway Time-out</h1>
The server didn't respond in time.
</body></html>
: 0
this looks like a genuine 504 error of the cve.json endpoint? Only 2 users have seen this, so I am not sure what is there to be done @nottrobin any ideas?
@anthonydillon do you mean that the page shouldn't break completely for something so trivial as not being able to display the number of CVEs for that release?
I agree. I would think the right solution would be up generate the number of CVEs and notices client-side. That way the initial page response would be much quicker and the page couldn't possibly be brought down by the API.
On another note, I imagine that 504 from cves.json has something to do with https://portal.admin.canonical.com/C126357
It probably should be client side but to resolve this issue the API response should check if its an error first before attempting to decode it as JSON. The error is in HTML format.
@anthonydillon that doesn't seem like a huge priority here. We can already see that the response code was 504 from the API from this error can't we? So we know everything we need to know. The only further point of catching the error server-side would be if we wanted to do something smarter with it - like what? Are you suggesting we suppress the error and don't let it break the page? Because if that's the case, how do we make sure we know the error happened and come and fix it?
Overall I would prioritise moving the logic client-side, and not bother rewriting the error handling at all. Catching the error feels like overengineering to me.
If there is time to move this logic client-side then we should take that approach. I was suggesting that we should check the response code before blindly passing it to .json(). If the response is an error don't parse as json and raise an error.
OK sure, maybe someone could have thrown in a response.raise_for_status() line. Then you'd get an HTTP like exception name, rather than a JSONDecode error, which could be confusing.
But fixing that is far from top priority in my mind. If something is broken, and the code breaks, that's not bad going.
This seems to be done now. Last time this issue was seen by sentry was 8 months ago. Closing the issue.