When we released Greenwave 0.8 with the new subject_type API, it broke @pingou 's local Bodhi development environment where he was querying Greenwave production. We put out a quick fix in PR#252 as Greenwave 0.8.1. See that PR for some more background info.

However as a consequence of PR#252, Greenwave will now return a satisfied decision saying "no tests are required" if you try to ask it about a Bodhi update which doesn't exist:

$ http post https://greenwave.fedoraproject.org/api/v1.0/decision decision_context=bodhi_update_push_stable product_version=fedora-28 subject:='[{"type": "bodhi_update", "item": "FEDORA-2018-000"}]'
HTTP/1.1 200 OK
[...]

{
    "applicable_policies": [
        "taskotron_release_critical_tasks_for_stable",
        "atomic_ci_pipeline_results_stable"
    ],
    "policies_satisfied": true,
    "summary": "no tests are required",
    "unsatisfied_requirements": []
}

It does that even if you use the newer style API with subject_type and subject_identifier instead of subject:

$ http post https://greenwave.fedoraproject.org/api/v1.0/decision decision_context=bodhi_update_push_stable product_version=fedora-28 subject_type=bodhi_update subject_identifier=FEDORA-2018-000
HTTP/1.1 200 OK
[...]

{
    "applicable_policies": [
        "taskotron_release_critical_tasks_for_stable",
        "atomic_ci_pipeline_results_stable"
    ],
    "policies_satisfied": true,
    "summary": "no tests are required",
    "unsatisfied_requirements": []
}

Asking about a Bodhi update that doesn't exist should really be a 400 error response instead, because it means the caller has given Greenwave bad input and probably has a bug/mistake.

One option is to keep the current behaviour (ignore non-existent Bodhi updates) only when the request is a backwards compatible one with subject parameter. if the request uses subject_identifier then return 400.

A better option might be to just make it always an error, and find a different way for @pingou to develop Bodhi against Greenwave.