This is the check at https://github.com/fedora-infra/bodhi/blob/5b4dc1380c8ecb9372e3a66e0b8cb26aa5b0a677/bodhi-server/bodhi/server/validators.py#L1366 . To answer the question why several other kf6 updates between then and now got through fine, it's because they all went in under the other Bodhi path which applies to Rawhide and branched releases before the "updates-testing activation point". This check is a validator applied when changing the update's "request". On the Rawhide-ish path, when an update is pushed stable, its request is not changed, it's just kinda teleported straight to stable by the approve_testing script. The composed_by_bodhi property is the one that decides which flow is used. We are now on the other side of that conditional, which means that regardless of whether an autotime or autokarma threshold is reached or someone tries to do a manual push, it involves setting the "request", so it runs into this validator.

anyway, "doing something" about this might be ugly; we might have to monkeypatch an exception for this update into the prod Bodhi code or something. any better ideas?

I guess the other thing we could do is go into the db and just delete the erroneous update, or force its status to be unpushed/obsoleted.

I think changing the bad update in the database is probably better than screwing with the code.

I changed the old / bad one to obsolete (since we unpushed it anyway, this is actually making things more truthful. ;)

The update is on the way to stable now... please let us know if you need anything further.

Thank you. I can see the update has already landed to stable repositories.