And Lemmy has an issue with it’s backend implementation which sometimes causes multiple copies of a comment being posted without the posters knowledge.
It then gets flagged as spam and the poster banned. Ask me how I know.
As someone who implement a Lemmy client it might be a client side problem. If the server is struggling you will time out when sending the comment. If the client side has any sort of retry logic it will send the comment again. This can cause the comment to be posted multiple times. There might be a bug on the server as well but I know for sure it can be caused by the client.
It’s what you are describing, and it’s not a client problem. It’s impossible for a client to solve. You can’t tell whether a timed out request succeeded or not.
Idempotent network requests are a standard feature of many APIs - sending the same request multiple times should result in only one action being performed, but Lemmy doesn’t support them yet.
So yes, it’s “caused” by retries, but the bug is that the backend doesn’t properly support retries. Clients don’t do anything wrong.
They should do what Reddit does and by default make a 5 second rate limit of sending posts and comments, the first one gets accepted, the next ones get rejected within the 5 second ratelimit.
I’ve seen this concept called idempotency tokens. I thought it was common but a quick search didn’t find any articles on it so maybe the name is not that common.
And Lemmy has an issue with it’s backend implementation which sometimes causes multiple copies of a comment being posted without the posters knowledge.
It then gets flagged as spam and the poster banned. Ask me how I know.
As someone who implement a Lemmy client it might be a client side problem. If the server is struggling you will time out when sending the comment. If the client side has any sort of retry logic it will send the comment again. This can cause the comment to be posted multiple times. There might be a bug on the server as well but I know for sure it can be caused by the client.
It’s what you are describing, and it’s not a client problem. It’s impossible for a client to solve. You can’t tell whether a timed out request succeeded or not.
Idempotent network requests are a standard feature of many APIs - sending the same request multiple times should result in only one action being performed, but Lemmy doesn’t support them yet.
So yes, it’s “caused” by retries, but the bug is that the backend doesn’t properly support retries. Clients don’t do anything wrong.
They should do what Reddit does and by default make a 5 second rate limit of sending posts and comments, the first one gets accepted, the next ones get rejected within the 5 second ratelimit.
Another popular solution I see is to have the client generate a UUID when posting. Then the server can very easily tell if a request is a duplicate.
I’ve seen this concept called idempotency tokens. I thought it was common but a quick search didn’t find any articles on it so maybe the name is not that common.
Nonce, maybe?
Nonce is the opposite. It’s never supposed to be used more than once, right?
how do you know?
I searched for the issue when it happened to me and saw a bug report for it with the Lemmy devs confirming.
how do you know?
how do you know?
how do you know?
Well shit. At the same time the ban hammer seems a bit easy both ways :') Like you can at least look at the poster’s history…