this post was submitted on 07 Oct 2024
436 points (92.2% liked)

Ye Power Trippin' Bastards

296 readers
52 users here now

This is a community in the spirit of "Am I The Asshole" where people can post their own bans from lemmy or reddit or whatever and get some feedback from others whether the ban was justified or not.

Sometimes one just wants to be able to challenge the arguments some mod made and this could be the place for that.

Rules

Expect to receive feedback about your posts, they might even be negative.

Make sure you follow this instance's code of conduct. In other words we won't allow bellyaching about being sanctioned for hate speech or bigotry.


Some acronyms you might see.


Relevant comms

founded 3 months ago
MODERATORS
 

Also outs your report publicly, nice !

you are viewing a single comment's thread
view the rest of the comments
[–] idunnololz@lemmy.world 26 points 1 month ago* (last edited 1 month ago) (2 children)

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.

[–] dev_null@lemmy.ml 23 points 1 month ago* (last edited 1 month ago) (1 children)

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.

[–] idunnololz@lemmy.world 3 points 1 month ago* (last edited 1 month ago) (1 children)

It could/should be handled by the server but it's technically possible for the client to make due without it. You would need to handle it very carefully. For instance on timeouts, you can issue a get request to see if the comment posted. If it did then you do not issue another post.

[–] dev_null@lemmy.ml 2 points 1 month ago

Sure, that would work, but it's a hacky solution, and involves needing to send more requests in a scenario where requests are already unreliable.

[–] Draconic_NEO@lemmy.dbzer0.com 5 points 1 month ago (2 children)

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.

[–] idunnololz@lemmy.world 14 points 1 month ago (2 children)

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.

[–] JackbyDev@programming.dev 6 points 1 month ago (1 children)

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.

[–] PoolloverNathan@programming.dev 1 points 3 weeks ago (1 children)
[–] JackbyDev@programming.dev 1 points 3 weeks ago

Nonce is the opposite. It's never supposed to be used more than once, right?

[–] dev_null@lemmy.ml 2 points 1 month ago

Yeah, that's the proper fix.

[–] dev_null@lemmy.ml 2 points 1 month ago* (last edited 1 month ago) (1 children)

It doesn't solve the problem of your comment request timing out after waiting 30 seconds in a spotty mobile connection. Now that it timed out, you don't know if it was actually posted or not. A proper API would not post duplicate comments in response to retries of a request that already succeeded (without the client knowing).

[–] Draconic_NEO@lemmy.dbzer0.com 1 points 1 month ago

That's a good point, I like @idunnololz@lemmy.world solution better. Make the request have it's own identifier and if one goes through disregard the rest.