Tor initialization and disposal #1560
Merged
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
str4d
approved these changes
Aug 14, 2024
HonzaR
approved these changes
Aug 16, 2024
Milan-Cerovsky
added a commit
that referenced
this pull request
Aug 21, 2024
* cargo update * rust: Remove unused direct dependencies * Migrate to Rust 1.79 * Migrate to latest revision of librustzcash crates * Add ZIP 320 TEX address validation * Migrate to latest revision of librustzcash crates This includes support for creating transaction proposals that send to TEX addresses. * Fix handling of empty memos This fixes several existing issues: - The Rust backend's `proposeTransfer` expected to receive `null` for no memo, but was instead receiving an empty array. `proposeShielding` meanwhile was always expecting a memo. - The Kotlin side had nullable byte arrays, but then always converted an empty string to an empty byte array instead of `null`. * Fix Detekt warning * Changelog update * Exception reporting issue filed Filed a follow-up issue #1534 * Add WalletAddress.Tex type * Another fix of Detekt warning * Migrate to latest revision of librustzcash crates * Raise MSRV to 1.80 * Fix clippy lints as of 1.80 * cargo update * Add `Synchronizer` APIs for USD/ZEC exchange rate * Exchange rate implementation (#1537) * Exchange rates API refactor * Code cleanup * Demo app updates * Exchange rate implementation * Detekt and ktlint checks * Code cleanup * Address review comments * Code cleanup * Code cleanup * Tor initialization and disposal (#1560) * Tor initialization and disposal * Code cleanup * Integrate transaction status queue for transparent history * Fix RawTransactionUnsafe to handle height response correctly * Migrate to latest revision of librustzcash crates * Expose transaction_data_requests and set_transaction_status across JNI * New usage of setTransactionStatus - Distinct between decryptAndStoreTransaction and setTransactionStatus path by minedHeight - Convert from RawStatusUnsafe to TransactionStatus - Add RawTransaction object and related functions - These changes resolve older issue #1254 * New usage of transactionDataRequests - New backend.transactionDataRequests and related logic is now used within CompactBlockProcessor - getTAddressTransactions from LightWalletclient module is now newly used - These also changes remove now unused querying transactions-related functions from v_transactions * Decrypt and store all types of transactions In case of SpendsFromAddress flow * Fix passing JniTransactionDataRequest to Kotlin * Fix ktlint and detekt warnings * Changelog update * Code cleanup * Process SpendsFromAddress on stream Instead of consuming the stream into list and working with list * Fix ktlint warnings * Target latest librustzcash commit * Move to the latest Rust crates commit * Change setTransactionStatus trigger Handle setTransactionStatus by TransactionDataRequest rather then minedHeight * Fix getTAddressTransactions input range --------- Co-authored-by: Honza <[email protected]> * Update to the latest zcash dependencies - `zcash_address 0.4` - `zcash_client_backend 0.13` - `zcash_client_sqlite 0.11` - `zcash_primitives 0.16` - `zcash_proofs 0.16` * Documentation update * Fetch transaction error handling * Update CHANGELOG.md Co-authored-by: Kris Nuttycombe <[email protected]> * Fix handling of ``OrphanedBlock` in `RawTransactionUnsafeExt` --------- Co-authored-by: Honza <[email protected]> Co-authored-by: Milan <[email protected]> Co-authored-by: Kris Nuttycombe <[email protected]> Co-authored-by: Kris Nuttycombe <[email protected]>
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.
Author
Reviewer
Footnotes
Code often looks different when reviewing the diff in a browser, making it easier to spot potential bugs. ↩
While we aim for automated testing of the SDK, some aspects require manual testing. If you had to manually test
something during development of this pull request, write those steps down. ↩
While we are not looking for perfect coverage, the tool can point out potential cases that have been missed. Code coverage can be generated with:
./gradlew checkfor Kotlin modules and./gradlew connectedCheck -PIS_ANDROID_INSTRUMENTATION_TEST_COVERAGE_ENABLED=truefor Android modules. ↩Having your code up to date and squashed will make it easier for others to review. Use best judgement when squashing commits, as some changes (such as refactoring) might be easier to review as a separate commit. ↩
In addition to a first pass using the code review guidelines, do a second pass using your best judgement and experience which may identify additional questions or comments. Research shows that code review is most effective when done in multiple passes, where reviewers look for different things through each pass. ↩
While the CI server runs the demo app to look for build failures or crashes, humans running the demo app are
more likely to notice unexpected log messages, UI inconsistencies, or bad output data. Perform this step last, after verifying the code changes are safe to run locally. ↩