@normandy @angristan @eal very likely. Might need to limit mass request since it will obviously jam JP’s queue
@Sujiyan @normandy @angristan @eal I do not know if this case corresponds to the following cases. For your reference.
I also had a "Delete Activity Storm" on fedibird.com. At first, I thought it was coming repeatedly from the origin of the Delete Activity, but it wasn't.
This was due to an exception that occurred when the Delete Actor's Delete Activity was being verified because the target Actor no longer exists and Sidekiq would retry the job.
@Sujiyan @normandy @angristan @eal The deleted account will be held for a while to meet these verifications. However, it will be deleted when the deadline expires. The server may go offline. It may be delayed in response to the deletion and may not be in time. A retry that has been sleeping for a long time also occurs when you manually retry it.
@Sujiyan @normandy @angristan @eal ActivityPub::ProcessingWorker must not be present in sidekiq retries if the user or server has been deleted. Also, this worker is unlikely to succeed on retry, so it may be better to remove it uniformly from retries.