- the most simple fix for this issue is to set the number of attempts to the "infinity"
- smarter solution will require a better retry logic in general, covered in #1304
- There was a reset missing in the rewind() call. This method is a direct call affecting the state of the compact block processor but the ActionContext has been handled only in the synchronization pipeline. Manual reset was needed to reset the last enhanced height.
- tests added
- Removed deprecated zip-313 fee of 1000 Zatoshi
- default is now 10k zatoshi, the minimum defined by zip-317
[#1294] Remove all uses of the incorrect 1000-ZAT fee
- changelog update
- InternalSyncStatus as well as SyncStatus were extended with stopped state, this is needed to distinguish between upToDate and stopped via stop() method states as previously stopped state of block processor was mapped to upToDate
- Execution of any query in TransactionSQLDAO was not thread safe. Since all queries goes through execute() method, this is now using a lock
[#1281] Database is locked
- global lock used, all rust backend code accessing data DB is under lock
- transactionsqldao is also under same lock
[#1281] Database is locked
- refactor + fbDB locked as well
[#1281] Database is locked
- lock around scalars added
[#1281] Database is locked
- comments addressed
- scalarLocked helper implemented
- connection().run and .transition locked as well
[#1281] Database is locked
- db used so it's not called twice
[#1281] Database is locked
- AccountEntity protected via globalDBLock as well
This fixes an issue where the transaction index was incorrectly being
used to filter out transactions from the contents of the
`v_transactions` view, and updates the query to account for the fact
that both the block time and the transaction index may be NULL in the
results of this view.
- latestBlockHeight (chain tip) reported in the SynchronizerState to the clients is now updated every 10mins at most, typically with every sync run (10-30s)
- fully and max scanned heights update fixed
- new mocks provided and tests fixed
The improved performance provided by `shardtree` is sufficient to allow
100-block scan ranges throughout the sandblasted range, and limiting to
10 blocks results in significant overhead.
A future release will switch to an adaptive strategy which can
dynamically adjust download and scan range sizes based upon observed
output counts and scanning times to provide consistent throughput.
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.
Kris Nuttycombe
Lukas Korba
Lukas Korba
Francisco Gindre