Create a content review cinderjob on created webhook payload

[eviljeff]

Fixes: mozilla/addons#15973

Description

Adds webhook integration that recognises a job created event on the back of the content review workflow, and creates a CinderJob for it, which would persist if the job was moved/escalated out of the content review queue.

Context

It's not as clean as tracking the job from the event id, but it does mean we don't need to keep track of event ids - and there should only be one job per add-on anyway, and one reason for the job being created.

Testing

• enable content-review-in-cinder waffle switch
• trigger the event that creates a content review job in cinder, e.g. edit an add-ons name or summary
• replay the "job actioned" payload from Cinder
• see a CinderJob is created (look with django shell) for that add-on, with content_review=True

Checklist

• Add #ISSUENUM at the top of your PR to an existing open issue in the mozilla/addons repository.
• Successfully verified the change locally.
• The change is covered by automated tests, or otherwise indicated why doing so is unnecessary/impossible.
• Add before and after screenshots (Only for changes that impact the UI).
• Add or update relevant docs reflecting the changes made.

[diox]

When replaying my payload I got:

{
  "amo": {
    "received": true,
    "handled": false,
    "not_handled_reason": "Unsupported source (api) for job.actioned:created"
  }
}

[eviljeff]

When replaying my payload I got:

{
  "amo": {
    "received": true,
    "handled": false,
    "not_handled_reason": "Unsupported source (api) for job.actioned:created"
  }
}

Can you link to the payload you used? I'm guessing there was other interaction/testing going on at the same time (QA?) and you chose one of those instead. All the content review jobs should come via source workflow rather than directly from api.

[diox]

You're correct, I had the wrong payload... It looks like what happened is that Cinder already had an opened job for the add-on I used, and as a result we never got a job.actioned event. But then is that an edge case we should worry about?

For debugging:

In Cinder, the job is https://mozilla-staging.cinderapp.com/job/ec9a6dd1-ffe1-4e00-9a4a-f72e737c4f48 which was created yesterday (I was not using this PR's branch then). I don't have that job locally. I do see in the worker logs the task succeeding:

{
  "Timestamp": 1775644563713181184,
  "Type": "celery.app.trace",
  "Logger": "http_app_addons",
  "Hostname": "b7f013504ea2",
  "EnvVersion": "2.0",
  "Severity": 6,
  "Pid": 12218,
  "Fields": {
    "data": {
      "id": "9d4b8741-bfa1-44bc-b51f-3b4a99c80ee5",
      "name": "olympia.abuse.tasks.submit_addon_change_for_content_review",
      "return_value": "None",
      "runtime": 0.9066050183027983,
      "args": "()",
      "kwargs": "{'activity_log_pk': 601}"
    },
    "uid": "",
    "remoteAddressChain": "",
    "msg": "Task olympia.abuse.tasks.submit_addon_change_for_content_review[9d4b8741-bfa1-44bc-b51f-3b4a99c80ee5] succeeded in 0.9066050183027983s: None"
  },
  "severity": 200
}

[eviljeff]

You're correct, I had the wrong payload... It looks like what happened is that Cinder already had an opened job for the add-on I used, and as a result we never got a job.actioned event. But then is that an edge case we should worry about?

It shouldn't happen on prod, because we'll get the notification when the job is first created.

If it does happen we'd still process the decision if it was made in Cinder, just we wouldn't have the associated job to mark it as a content job (a problem operationally only if the job was forward/escalated; but also if that data is relied on at some point).