Closes#614
fixes travis ci
Removed `setStartHeight` function
I’m going back in time and this setHeight is not something we are using anywhere else than in the prepare function. This comes from the times we had `initialize(seed:birthday) and we don’t have that anymore
See diff 246d10edaa (diff-414771774e10bc81260094ffcdc7b310a3be48758b2abd2bfae831c83912c02c)
The `func setStartHeight(_ startHeight: BlockHeight)` function assumes that
there might not be a wallet birthday set up or that it might be changed
in-flight which are things that are no longer happening.
remove test warning
Fix test compiler error
Closes#619
- When computing next action in `NextStateHelper.nextStateAsync` now
scanning state is also taken into consideration.
- When processing blocks download phase is skipped when it's detected
that everything is already downloaded.
`XCAsyncTestCase` does not work as intended but `wait {}` does what
we need.
restored `needsToStartScanningWhenStopped` as a Bool var on actor
fixed Enhancement test
Closes#579
This is what happens when database was locked:
- App is syncing.
- While rustBackend.scanBlocks(…) is in progress app goes to background. Background task is launched and
ECC works for some time in background.
- When background task is finished synchronizer.stop() is called.
- Inside CompactBlockProcessor.stop()is called. In this method cancelableTask is canceled and state is
set to stopped no matter what. And this is the problem. Because even when canceled is called rust
scanning isn’t canceled. But state doesn’t care about it. And next time when app is launched new
synchronisation is started and now you have processing code running in two threads causing DB lock.
So I moved setting state to stopped to processNewBlocks method. It's set
after the work is canceled and really stopped. When doing this there is
still one problem. When app goes to foreground new sync is not started
and current one is just stopped.
So I added new variable and condition. And when this variable is set
to true new syncing process starts when the previous one is canceled.
This should cover all the problems.
- Test was failling with:
generalError(message: "block not found in cache, should always be in cache in darkside mode")
- There was no wait so lightwalletd in darkside mode didn't have enough time to accept mocked state.
- Sample app refactored for the processor being an actor
- tests refactored as well
- dark side tests fixed
- utilities separated to new file
- synchronizer's start and stop are no longer in async context
- updating the UI for the scan fixed
Currently a 100 batch can take up to 3 minutes to scan. decrease the size of the batches when the increased load part of the chain is reached until a faster sync is implemented
See related counterpart to remove it issue #576Closes#577