if you got affected by the federation killer by akkoma on your *key or firefish instance, there are 2 tables, you'll need to fix the shared inbox on.
one is "sharedInbox" on the "user" table. you can adapt floaty's query quite easily with it, just use "inbox" instead of "ap_id" and map the other fields accordingly
the other place (which is the more important one) is to reset the field "followerSharedInbox" in the "following" tables. i don't have a good query for that, since i only had a couple of entries there which needed fixing. but i'm sure you can figure one out to make the update using a join on the user table or something.
after the fields are updated, federation should work again
also this happens on user by user basis, depending on who is following and stuff. so one user might be able to federate, while another user on the same instance can't.
@hazelnoot@enby.life the issue is, that posts made by users who are affected by this will not even get to the queue in the first place.
and no, jobs are not retried for forever, there is a limit (which you can reset in your config yaml) at which the jobs is gonna get dropped all together
@puniko@mk.absturztau.be Wait, is there actually no mechanism at all to remove a delivery job after an exception? It really just retries forever??? Please tell me I misread that code :neofox_shocked:
@tastytea@very.tastytea.de yes, its not running akkoma. the akkoma bug caused an akkoma instance to announce a users shared inbox with an invalid url (/inbox in this case). it gets updated like that user does a profile update, causing remote instances to reset the shared inbox for that user to this invalid url
@orsinov@our.unknowing.dance one of the recent commits in akkoma have accidently set the shared inbox to an invalid url. and this url federated, causing remote instances problems with federation