@mint @amerika @p @FranciscoScaramanga @GummyNerds @PNS @eriner @sun The lowest priority doesn't matter that much. It will all get executed when there's nothing else to do, which will still cause the DB activity to spike anyway and cause problems for when the real things have to be done. Add Postgres timeouts and retries to the mix and things sometimes barely work.(1) Oban doesn't seem to take into account the time it took to execute the previous low priority job when deciding if it should run the new job from the same worker with the same priority.
It should probably be batched and the batch execution should happen only after X amount of time has passed from the previous one. It might be doable with Oban, but I don't really know.

Not that it is an important thing to do, when the MRF policy is publicly known and fixing it should be done on the Mastodon or reverse proxy side, instead of mitigating their incompetence in Pleroma. And the current solution mostly works apart from the user creating spam that already has an open MR anyway. Akkoma users just have to deal with it, the same way they have to deal with other FloatingGhost's "interesting" ideas.

(1) This is also one of the "skill" issues that some Pleroma instance owners complain about. It's trivial to fix with an MRF policy or a quick nginx rate limit rule, but some people will still say that Pleroma "just sucks" at being a Fediverse server, because it doesn't completely work out-of-the-box in every situation.