With the fixes to `v_transactions` and `v_tx_outputs`, there are
several more data fields that may have no data (for rows corresponding
to purely-transparent transactions); their fields are made nullable.
* [#1241] Remove rewind for every verify scan range
- The original solution comes from the pseudocode requirement: Download the blocks in `scan_range` into the block source, overwriting any existing blocks in this range.
- Removed
* [#1243] Rewind only after continuity-error
- Rewind is done only when Continuity-error appears now. In case of other sync failures, the sync loop sleeps for a short time and then retries. Internal actions like fetching subtree roots, fetching chain tip, downloading, scanning, etc., still have their internal retry mechanisms.
- For the calculation of the rewind height, we use the existing checkContinuityErrorResult method, originally used only for validation use cases but later incorrectly used for other failures too.
- Closes#1243
- Closes#1222 as it was created to determine which failure type comes and don’t rewind for all of them
- Tested manually in several scenarios, e.g. lost internet connection or app going to background
* Handle Continuity and other sync errors
- Call handleContinutyError and its rewind logic directly without checking failed attempts. This ensures that we keep trying to reorg.
- And return the correct type of error in that case.
- Add fail logic to the handling of the other types of errors.
* Add JniScanProgressTest
* Remove unnecessary testnet workaround
As this was fixed with the last rust changes.
* Simplify batchCount calculating
* Fix ratio typo
* Docummentation comments changes
- TypesafeBackend.createAccountAndGetSpendingKey now works with a type-safe TreeState model class instead of ByteArray.
- New type-safe TreeState added. Once we get the TreeState object from the lightwalletd server, potential validation comes into this object.
This works around zcash/librustzcash#948, where known accounts without
history are not reported in the `WalletSummary`. We assume that the
Kotlin side of the SDK does not call these FFI methods with unknown
accounts.
* [#1170] Regular transaction flow emitting
Although zcash/librustzcash#918 will provide information on when to trigger transaction polling, this partly solves the issue as well
* Update changelog
Jack Grigg
Jack Grigg
Honza Rychnovský
Kris Nuttycombe