JBI could fail at parsing Webhook incoming request with:
a regression/bug is introduced in our code (eg. while working on #234)
working on new kinds of events (eg. #397)
a change in Bugzilla server
Currently, JBI logs the error and returns HTTP 422.
We may want to leverage the queue to return HTTP 200 instead and store the payload.
option 0: status quo
Do not change current behaviour
option 1: refactor queue code to allow arbitrary payloads
Current code uses track_failed(payload: bugzilla.WebhookRequest, exc: Exception)
In order to be able to store the invalid incoming payload in the queue, we would have to modify the queue methods and models to allow arbitrary payloads.
This would prevent us from accessing payload attributes like this:
JBI could fail at parsing Webhook incoming request with:
Currently, JBI logs the error and returns
HTTP 422.We may want to leverage the queue to return
HTTP 200instead and store the payload.option 0: status quo
Do not change current behaviour
option 1: refactor queue code to allow arbitrary payloads
Current code uses
track_failed(payload: bugzilla.WebhookRequest, exc: Exception)In order to be able to store the invalid incoming payload in the queue, we would have to modify the queue methods and models to allow arbitrary payloads.
This would prevent us from accessing payload attributes like this:
https://github.com/mozilla/jira-bugzilla-integration/blob/7f99b9ee2498a951cc4f3e4ec13d653c0990a9db/jbi/queue.py#L80
Turning the arbitrary payload into
WebhookRequestwould happen explicitly in theretry_failed()code before callingexecute_action()option 2: add new queue method
Instead of changing the models we could add backend and queue methods:
track_invalid(payload: Any, exc: Exception)backend.put_raw(item_raw: Any, exc: PythonException)This would store the content in the queue, assuming that the retry job won't be able to process the content until the code is changed and redeployed.