17
Why do comments differ across instances?
(feddit.uk)
Community for the Feddit UK instance.
A place to log issues, and for the admins to communicate with everyone.
Sometimes instances are overloaded which cause federation events to timeout and be dropped. Since federation is a push event when this happens, it cannot be recovered
I see. I'll assume this is a problem related to the surge in users and will eventually resolve itself.
Lemmy.world has been struggling hard core the last couple days, sometimes not even loading. I think this is an issue with a free service that requires actual intense server hardware when you scale like this. Hopefully they can find a sustainable way to deal with their increased usage.
Is that not a pretty big weakness to Lemmy? I know it's never going to be perfect, but if Lemmy is to appeal to more people I feel issues like this add friction and makes Lemmy appear to be a little quiet/confusing as a result.
For instance, I have two Lemmy profiles - one on Feddit.uk and one on FMHY - both have different comments on the same post in !gaming@beehaw.org
I say, stop worrying and enjoy the chaos! So you miss a few comments here and there, so what? There's plenty more around and as the traffic increases more and more, we can't keep up with all this content anyway.
Seems like the events should get pushed onto a queue so that if the instance is overloaded or down, the events aren't lost.
The problem is in the way ActivityPub works. The events are pushed into the queue, but if the receiving system takes too long to process it, there's a datetime "expiry"
Ah, I'm totally unfamiliar with ActivityPub (never even heard of it until now!). Is the expiry time of the messages totally uncontrollable by Lemmy then?
No, It's part of the ActivityPub protocol definition
I had a look at the ActivityPub W3C and I noticed the following paragraph:
In this context is 3rd party server a federated server? I couldn't see where expiry came in but presumably if the pushes are async then the server sending the payload won't know if it succeeded or not (unless there's some other mechanism to verify message acknowledgment).
The async doesn't mean if the sending server doesn't know. It's not using UDP lol :) It will retry until it gets a RC 200 or 201. Then stop sending. The asynchronous part is that the receiving instance doesn't have to import the event into the DB immediately. The received event sits in a special "to import" queue until processed. Each event has a timestamp attached to it. If it takes too long to process the event in the queue, because the receiving server is overloaded, then its timestamp may be considered expired.
E.g. from https://blog.joinmastodon.org/2018/06/how-to-implement-a-basic-activitypub-server/