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.
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.
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.
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.
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.