You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jan 18, 2019. It is now read-only.
It is my understanding that tefALREADY should be returned when trying to submit a transaction that is already being applied to a ledger. From discussions with @MonsieurNicolas , this is flaky. This brings me to the first issue:
We should guarantee that tefALREADY will always be returned in the case of a duplicate transaction submission to a node that is already trying to apply the transaction.
Secondly, if a duplicate transaction (hash) is being submitted and the transaction is already in a closed ledger, right now stellard returns tefPAST_SEQ. IMO tefPAST_SEQ should be reserved for submitted transactions that have the same seq number as an already submitted transaction but a different hash. That brings me to my second issue:
Return a different error than tefPAST_SEQ if we're trying to submit a duplicate transaction that has already been included in a closed ledger.
The text was updated successfully, but these errors were encountered:
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
It is my understanding that tefALREADY should be returned when trying to submit a transaction that is already being applied to a ledger. From discussions with @MonsieurNicolas , this is flaky. This brings me to the first issue:
Secondly, if a duplicate transaction (hash) is being submitted and the transaction is already in a closed ledger, right now stellard returns tefPAST_SEQ. IMO tefPAST_SEQ should be reserved for submitted transactions that have the same seq number as an already submitted transaction but a different hash. That brings me to my second issue:
The text was updated successfully, but these errors were encountered: