I had a dumb thing in my #ActivityPub implementation.
-
I had a dumb thing in my #ActivityPub implementation.
I was getting these broadcast Delete announcements tied to Person objects from servers out in the wild, and was dutifully trying to validate their signatures. I didn't have the key here, and they're signed by the deleted Person, so loading the key gave a 404.
So the next thing it tried to do was see if loading the Person remotely gave a 404, and if so, it's a legitimate Delete, problem solved.
But what I think was happening was that the attempt to load the Key, then the attempt to load the Person, both flagged the remote server "hey this guy doesn't know about the Delete", and it received another copy of the Delete action. It's possible each Delete caused two copies of itself to get re-queued. Holy forkbomb.
So I stuck a little bit at the top of Delete validation that checks to see if I have the target object, and chucks the message in the bin if not. This was in my original implementation but got lost when I did some refactoring.
It sat for an hour, just processing THOUSANDS of backed up Delete messages.
-
I had a dumb thing in my #ActivityPub implementation.
I was getting these broadcast Delete announcements tied to Person objects from servers out in the wild, and was dutifully trying to validate their signatures. I didn't have the key here, and they're signed by the deleted Person, so loading the key gave a 404.
So the next thing it tried to do was see if loading the Person remotely gave a 404, and if so, it's a legitimate Delete, problem solved.
But what I think was happening was that the attempt to load the Key, then the attempt to load the Person, both flagged the remote server "hey this guy doesn't know about the Delete", and it received another copy of the Delete action. It's possible each Delete caused two copies of itself to get re-queued. Holy forkbomb.
So I stuck a little bit at the top of Delete validation that checks to see if I have the target object, and chucks the message in the bin if not. This was in my original implementation but got lost when I did some refactoring.
It sat for an hour, just processing THOUSANDS of backed up Delete messages.
squinky@teh.entar.net oh god that sounds nuts... also a weird sort of thing for the other server to do isn't it. Seems like just sending the message once would be enough!