changes timestampToTransactionHash to one-to-many #3625
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
hughy
force-pushed
the
fix/timestamp-to-many-tx
branch
from
c565c3d
to
3e0e52f
Compare
danield9tqh
reviewed
Mar 8, 2023
danield9tqh
approved these changes
Mar 10, 2023
dguenther
approved these changes
Mar 10, 2023
it's possible for multiple transactions to have the same timestamp in a wallet. for example, if an account receives two transactions that are on the same block, but did not sync those transactions until they were on the chain, then both transactions will have the block header timestamp. this example might occur in practice if a node was offline when the transactions were first created and/or did not receive the transactions in gossip messages before they were added to the chain. this might also happen for an account that is imported to a wallet after the transactions were added to the chain. when rescanning the chain for the imported account all transactions will use the timestamp of the block header of the block they are found on. we use the 'timestampToTransactionHash' index to load transactions in order for the 'getAccountTransactions' RPC. the impact of the one-to-one datastore is that the RPC would miss transactions that the account has.
ensure that the right transactions are returned from getTransactionsByTime in the expected order
hughy
force-pushed
the
fix/timestamp-to-many-tx
branch
from
865abea
to
b5da5ae
Compare
do not expect on ordering for accountA transactions - fixture generation sets
the timestamps for pending transactions to be equal to the time of the
test run, so we cannot maintain ordering on these timestamps right now
hughy
force-pushed
the
fix/timestamp-to-many-tx
branch
from
da553d1
to
03fc7dd
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
it's possible for multiple transactions to have the same timestamp in a wallet.
for example, if an account receives two transactions that are on the same block, but did not sync those transactions until they were on the chain, then both transactions will have the block header timestamp.
this example might occur in practice if a node was offline when the transactions were first created and/or did not receive the transactions in gossip messages before they were added to the chain.
this might also happen for an account that is imported to a wallet after the transactions were added to the chain. when rescanning the chain for the imported account all transactions will use the timestamp of the block header of the block they are found on.
we use the 'timestampToTransactionHash' index to load transactions in order for the 'getAccountTransactions' RPC. the impact of the one-to-one datastore is that the RPC would miss transactions that the account has.
Testing Plan
wallet:transactionsafter migrationBreaking Change
Is this a breaking change? If yes, add notes below on why this is breaking and
what additional work is required, if any.