ubuntu.com icon indicating copy to clipboard operation
ubuntu.com copied to clipboard

JSONDecodeError: [Errno Expecting value] <html><body><h1>504 Gateway Time-out</h1>

Open anthonydillon opened this issue 3 years ago • 6 comments

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

anthonydillon avatar Jan 12 '22 10:01 anthonydillon

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?

carkod avatar Jan 14 '22 10:01 carkod

@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

nottrobin avatar Jan 14 '22 23:01 nottrobin

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 avatar Jan 14 '22 23:01 anthonydillon

@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.

nottrobin avatar Jan 17 '22 13:01 nottrobin

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.

anthonydillon avatar Jan 17 '22 14:01 anthonydillon

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.

nottrobin avatar Jan 17 '22 15:01 nottrobin

This seems to be done now. Last time this issue was seen by sentry was 8 months ago. Closing the issue.

tbille avatar Feb 21 '23 19:02 tbille