We noticed this last night while trying to waive some failures and push the DNF 5 reversion update stable. You can still see the problem on the update page for that update, though unfortunately all the messing around has left things a bit unclear:

https://bodhi.fedoraproject.org/updates/FEDORA-2023-5fd964c1bf

If you use the browser console to get the raw greenwave response for the update, the summary is "3 of 57 required tests failed" and the 'waivers' section of the response lists only two waivers, id 16110 and 16109. This is despite the fact that there are actually a lot more 'current' waivers for the update. As you can see at https://waiverdb.fedoraproject.org/api/v1.0/waivers/?subject_type=bodhi_update&subject_identifier=FEDORA-2023-5fd964c1bf , as well as 16110 and 16109, there are waivers 16107 and 16108, plus some additional waivers from earlier situations where more tests had failed.

I believe the reason why greenwave doesn't see all the active waivers is that there's a bug in the waivers/+filtered API endpoint, which greenwave uses on this path. As long as include_obsolete is not in the query args, the FilteredWaiversResource.post() method which backs this API endpoint groups tries to find only 'current' waivers. It does this by grouping waivers by subject_type, subject_identifier, and testcase, then taking only the highest waiver ID from each group. The problem is that it doesn't also group by scenario. So if we have multiple waivers for the same subject_type, subject_identifier and testcase - but different scenarios - this API endpoint will only return one waiver from that set (the highest numbered, whichever scenario that happens to be).

I will send a PR to fix this, just wanted an issue to explain the problem and for the PR to point to.