Duplicate transactions were broadcasted
Closed this issue · 5 comments
Generic information
- OS name and version: unknown
- Application build code: unknown
- Network type (mobile/Wi-Fi): unknown
Bug description
I found these two transactions are exactly the same but they were broadcasted in different height and stored on state.
If the user intended to post two different polls, the end dates should be different. I expect there is some issue after the user posted the first poll.
@kwunyeung The two transactions are valid since they were posted in two different blocks.
If the user intended to post two different polls, the end dates should be different.
Actually, I think this is not fair. A user might want to post two different polls (different question) that ends on the same date.
What I think we can do, instead, is checking whether there is already an identical poll from the same user when creating it. So we check if the question and the answers are the same, and we avoid posting it. This would be better, what do you think?
A user might want to post two different polls (different question) that ends on the same date.
I agree but when I checked the two transactions, they have exactly the same ISO date "end_date": "2020-09-30T08:58:39.535Z". So the two transactions seems not intentionally two separate polls. I wonder if Mooncake mistakenly broadcasted the same transaction with a new signature.
Checking the question and answer is not good as user may really want to post same question/answers at a different time.
@kwunyeung Looking at this problem more in depth, I realized that it is caused by an entirely different thing.
Currently when we store the posts offline inside the user device, we use the post creation time to uniquely identify each post. This was done because in previous versions of Desmos we could specify such times locally and then the chain would use them.
With the latest version, instead, the chain does not care anymore about the specified time. Instead, it uses the block time as the post creation time, returning that.
So, currently what happens is the following:
- We store the post locally, identifying it by the local creation time.
- We send the post to the chain, which returns it with the chain creation time.
- When it's time to save it, the two keys will now be different due to the different creation times.
This will result in double posts being displayed.
@RiccardoM but the issue here is about the two identical transactions, not one content being displayed twice. Would this be solved if the different key issue is fixed?
@kwunyeung Yes, this would be solved. We currently have fixed this by using the post hash as a local key. This was no double posts are produced. We will publish a 5002 build shortly.