Use SQLite in integration tests scenarios (instead of MVar) #406
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
KtorZ
force-pushed
the
KtorZ/sqlite-in-integration-scenarios
branch
from
14fcfeb to
9ae58b8
Compare
rvl
approved these changes
Jun 13, 2019
|
Seems like the integration tests are hanging forever in case of failure, like something preventing the thread from dying. I guess that because the SQLite connection is never closed. I'll have a look. |
…rmed UTxO from a checkpoint
The SQLite implementation was storing 'totalUTxO' which is completely invalid since this:
- does not contain the pending UTxO
- does contain the change UTxO
So, after storing a checkpoint and recovering it from the DB, we'll end up with the same UTxO as-if all pending
txs were accepted and not pending anymore.
…-machine when reading checkpoint Pending transactions can actually be inserted independently of the wallet checkpoints. So, if we insert a checkpoint after we inserted some pending txs, reading that checkpoint again should yield those pending txs.
…toring checkpoint
paweljakubas
approved these changes
Jun 13, 2019
KtorZ
force-pushed
the
KtorZ/sqlite-in-integration-scenarios
branch
from
378313f to
f79f3a3
Compare
KtorZ
force-pushed
the
KtorZ/sqlite-in-integration-scenarios
branch
from
f79f3a3 to
39bcc46
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.
Issue Number
#154
Overview
totalUTxOwhen storing the checkpoint, which is a modified version of the actual checkpoint UTxO. Fixed by providing a new accessor to get the "raw" UTxO of a checkpoint.PendingTxtable storing pending transactions identified by the wallet id and a slot. That is redundant with theTxMetaalready stored, plus, it was not maintained properly and wouldn't yield the correct pending txs when restoring a checkpoint.repsertinps and outs when inserting pending txs of a checkpoint because inputs or outputs may have been inserted by some previous transactions!Comments
It'd be nice to find some sort of invariant to enforce regarding pending txs and the corresponding checkpoint. We don't expect
putTxHistoryto be called without aputCheckpointfollowing either before or after. One way to deal with this could be:putTxHistoryis never called with pending txsTxMetain the checkpoint, such thatputCheckpointhas enough information to fully store a pending tx.edit: Addressed points above in a last commit.