INACTIVE. Server in the Stellar network. Maintains the distributed ledger. Introduces and validates transactions. This repo is not in active development, it is being replaced by stellar-core.
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:
1) 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:
2) 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.
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:
1) 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:
2) 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.