-
Notifications
You must be signed in to change notification settings - Fork 1.2k
Fail GetTransaction when the block from txindex is not in mapBlockIndex #3606
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
This indicates a previous crash where the TX made it into the txindex but the block was not flushed to disk. When dashd is restarted then, there is a short time where GetTransaction would return a non-existant block, while callers very often assume that the returned block hash is known.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
utACK, but just as im interested, do you have more details to share about where this issue/crash happens?
@xdustinface I obseved this while someone from the community was doing stress tests on testnet. Many of my nodes crashed due to OOM (I didn't reserve enough RAM per tMN) and then failed to start again, as they immediately received IS locks from other nodes which made them crash in IS code (here). Instead, the IS locks should have been handled as if the TX was unknown locally. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
utACK
@codablock thanks! So if i got it right it this means we have inconsistencies between the block data and the txindex if this happens? Is this at least resolved somehow later(probably when the block gets added properly again)? :D Also, could we prevent this by moving the txindex batch write from |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
utACK
@xdustinface Yes we have inconsistencies in the case of a crash, but we can ignore them (with this patch applied) as the only place where the index is read is in |
@codablock alright. Means we should keep an eye on the future usage of |
…ex (dashpay#3606) This indicates a previous crash where the TX made it into the txindex but the block was not flushed to disk. When dashd is restarted then, there is a short time where GetTransaction would return a non-existant block, while callers very often assume that the returned block hash is known.
backported in #3670 |
…ex (dashpay#3606) This indicates a previous crash where the TX made it into the txindex but the block was not flushed to disk. When dashd is restarted then, there is a short time where GetTransaction would return a non-existant block, while callers very often assume that the returned block hash is known.
This indicates a previous crash where the TX made it into the txindex but
the block was not flushed to disk. When dashd is restarted then, there is
a short time where GetTransaction would return a non-existant block, while
callers very often assume that the returned block hash is known.