fix: handle the case of invalid json gracefully

[weyert]

This changes the behaviour how invalid json is handled in the /decide-endpoint instead of failing hard by throwing a 500 internal server error it instead will throw a 400 Bad Request error instead to make the Developer Experience better

fixes #1576

Changes

Please describe.
If this affects the front-end, include screenshots.

Checklist

• All querysets/queries filter by Team (if this PR affects any querysets/queries)
• Backend tests (if this PR affects the backend)
• Cypress E2E tests (if this PR affects the front and/or backend)

[weyert]

Originally I want to use a custom exception handler and return 400 when JSONError exception is thrown but I am seem to unable to get my exception handler to get called. The main reason for this approach to change the behaviour for all API routes.

[yakkomajuri]

Thanks for this @weyert! I'll be giving it a look when I get the chance early next week! I'll look into the tests and make sure the changes fit nicely with #1553

[yakkomajuri]

Ok so this right now works but is not the way I want to handle it because it adds redundancy through calling _load_data twice. The approach @weyert is following here is drawn from our /capture endpoint, but I've now realized that the implementation /capture uses doesn't actually work to detect all malformed JSON. I'm working on it.

[yakkomajuri]

Ha, I've been hopping around timezones so my GitHub posts are happening "in the future".

"Yakko self-requested a review in 1h"

[yakkomajuri]

Ok so @weyert had mentioned that we should see if there are any other endpoints that could benefit from this approach. I think /capture potentially could. However, I'll merge this as it is somewhat "blocking" me on #1553 and then see with another PR the other endpoints this could be applied to.

Thanks for this @weyert! I definitely agree we should be throwing as few 500s as possible.

[weyert]

Thank you @yakkomajuri for looking and accepting my pull request :D