Although is not the best way to solve it this addresses the issue
in a single statement and following existing pattern in the code.
The error should be thrown earlier in RustBackend itself if so,
or fallback to some specific value that makes sense to the domain
Closes#1267
- more comments resolved
- totalProgressRange removed from the SDK
- ScanRange now takes into account the given value and properly initializes, + added tests
- tests fixed
- cbp_state_machine.png as well as .puml files updated to reflect the State Machine changes after SBS
- one small cleanup of clearCache, no longer needed to be called twice, only after enhance (missed removal of linear sync)
* Updates to `zcash-light-client-ffi 0.4.0-rc.1`
* Makes some cleanup updates to the CHANGELOG; a complete changelog will
be prepared for the 2.0.0 final release.
- CompactBlockProgress has been update to use syncProgress only
- CompactBlockProgressUpdate removed
- BlockProgress removed
- enhance and fetch progresses removed
- progressPartialUpdate refactored to syncProgress
- tests updated
- getScanProgress used for reporting of the syncing progress
[#1238] Report sync progress with the new getScanProgress
- comment added
[#1238] Report sync progress with the new getScanProgress (#1239)
- TODOs + offline tests fixed
- concept of linear syncing fully removed from the SDK, it's fully replaced with Spend-before-Sync
- BlockDAO - table blocks is no longer used, removed from the SDK and all it's associated getLastBlocks/ScannedHeights as with it
- concept of pending transactions removed from the SDK
- unit tests refactored
- My assumption was right, the way State Machine is done requires .celarCache to be called with every "restart"
- I was able to reproduce errors when clearCache wasn't called so the updateChainTipAction needed to be updated to prepare clean conditions for the scan suggest ranges
- tests updated
- the end of scan range is now properly filled
[#1223] Requested height [over latestheight] does not exist in the block cache
- the end of scan range is now properly filled
- unit tests for this change, checking if range.upperBound is set as expected
[#1223] Requested height [over latestheight] does not exist in the block cache
- code cleanup
- when getSubtreeRoots call fails on timeout, the connectivity is not present and the action must be terminated (throw) an error, this way when the connectivity is back, the State Machine starts over and getSubtreeRoots get a chance to properly decide if SBS is supported
[#1179] Handle false positive getSubtreeRoots when connectivity is down
- unit test for the timeout getSubtreeRoot added
[#1179] Handle false positive getSubtreeRoots when connectivity is down (#1222)
- warning fixed
- WIP
[#1176] Cover Spend before Sync with tests
- next batch of updates
[#1176] Cover Spend before Sync with tests
- last batch of fixes and new tests
[#1176] Cover Spend before Sync with tests
- package.resolved updated
[#1176] Cover Spend before Sync with tests (#1212)
- added tests for brand new actions related Spend before Sync
- RewindActionTests
- UpdateChainTipActionTests
- UpdateSubtreeRootsActionTests
- ProcessSuggestedScanRangesActionTests
- the computation of progress changed, the total range is computed, that way it works for any kind of sync algorithm
- the progress depends on finished scan action, whenever it processes some blocks, it's counted up
- the final progress is a ratio between these new values
draft
[#1165] Step 1 - Download note commitment tree data from lightwalletd
- code cleanup after draft
[#1165] Step 1 - Download note commitment tree data from lightwalletd
- UpdateSubtreeRootsAction added, ensuring the roots are downloaded and stored in the DB
[#1165] Step 1 - Download note commitment tree data from lightwalletd
- added ZcashError for putSaplingSubtreeRoots failure
- cleaned up action
[#1165] Step 1 - Download note commitment tree data from lightwalletd
- demo app config temporarily updated to Nighthawk server
[#1165] Step 1 - Download note commitment tree data from lightwalletd
- file header updated
[#1165] Step 1 - Download note commitment tree data from lightwalletd (#1174)
- demo app config cleaned up
[#1165] Step 1 - Download note commitment tree data from lightwalletd (#1174)
- offline tests fixed
- The State Machine has been slightly updated so it measures time when it lastly updated chain tip. If it happened more than 10mins ago, it calls the .updateChainTip action once again before the download-scan-enhance loop continues
- updated unit test
[#1206] Frequent call of update chain tip (#1207)
- whenever updateChainTip is called, it's followed by suggestScanRanges logic
- the computation of progress changed, the total range is computed, that way it works for any kind of sync algorithm
- the progress depends on finished scan action, whenever it processes some blocks, it's counted up
- the final progress is a ratio between these new values