Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[#1632] Refactor Account.DEFAULT #1645

Merged
merged 25 commits into from
Dec 4, 2024
Merged

Conversation

HonzaR
Copy link
Contributor

@HonzaR HonzaR commented Nov 29, 2024

Note
This code review checklist is intended to serve as a starting point for the author and reviewer, although it may not be appropriate for all types of changes (e.g. fixing a spelling typo in documentation). For more in-depth discussion of how we think about code review, please see Code Review Guidelines.

Author

  • Self-review your own code in GitHub's web interface1
  • Add automated tests as appropriate
  • Update the manual tests2 as appropriate
  • Check the code coverage3 report for the automated tests
  • Update documentation as appropriate (e.g README.md, Architecture.md, etc.)
  • Run the demo app and try the changes
  • Pull in the latest changes from the main branch and squash your commits before assigning a reviewer4

Reviewer

  • Check the code with the Code Review Guidelines checklist
  • Perform an ad hoc review5
  • Review the automated tests
  • Review the manual tests
  • Review the documentation, README.md, Architecture.md, etc. as appropriate
  • Run the demo app and try the changes6

Footnotes

  1. Code often looks different when reviewing the diff in a browser, making it easier to spot potential bugs.

  2. 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.

  3. 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 check for Kotlin modules and ./gradlew connectedCheck -PIS_ANDROID_INSTRUMENTATION_TEST_COVERAGE_ENABLED=true for Android modules.

  4. 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.

  5. 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.

  6. 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.

@HonzaR HonzaR force-pushed the 1632-remove-default-account branch 2 times, most recently from ae3796b to f3f98c3 Compare November 29, 2024 13:56
@HonzaR HonzaR marked this pull request as ready for review November 29, 2024 13:58
@HonzaR
Copy link
Contributor Author

HonzaR commented Nov 29, 2024

The failing tests need to resolve this comment in the underlying PR first #1640 (review)

@Milan-Cerovsky
Copy link
Contributor

crash - DerivationTool.getInstance().deriveUnifiedSpendingKey when deriving spending key
crash - Synchronizer.getAccounts when fast after restore wallet

feature request - getAccounts is fine as a function but please also add a flow

@HonzaR
Copy link
Contributor Author

HonzaR commented Dec 1, 2024

Thank you. I'll test both crashes.

crash - DerivationTool.getInstance().deriveUnifiedSpendingKey when deriving spending key

This one might be related to my comment above

crash - Synchronizer.getAccounts when fast after restore wallet

No quick thought about this one. I'll come back once reproduced.

feature request - getAccounts is fine as a function but please also add a flow

Yes, we'll need it when adopting in Zashi.

@HonzaR HonzaR requested a review from LukasKorba December 2, 2024 11:08
Copy link
Contributor

@str4d str4d left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewed db49a63. I did not review (most of) the changes to the test files.

This PR should be split into the changes that fix #1632 (which all LGTM), and the changes that finish #1640. Whether or not this happens outside of #1640 or by merging the PR into #1640 and then rebasing the branch to fix its commit history, I don't particularly mind; but the #1632 fixes need to merge before #1640 can be merged, because the latter blocks on the former.

@@ -31,7 +31,7 @@ sealed class TransactionRecipient {
override fun toString() = "TransactionRecipient.Address"
}

data class Account(val accountValue: cash.z.ecc.android.sdk.model.Account) : TransactionRecipient() {
data class Account(val accountZip32Index: Int) : TransactionRecipient() {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This change is incorrect. The value currently returned from the SQL view is the internal account ID, not the ZIP 32 account index. (This is where the SDKs were conflating internal account IDs with ZIP 32 account indices previously; we should not persist with this conflation.)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This one is tricky, as we currently don't have a way to get Account here. I just changed the parameter to val accountId: Int in this PR. And in #1640 I added this small change d9cd693. IIUC the iOS SDK has the same bug. I'll rise it.

@HonzaR HonzaR force-pushed the 1632-remove-default-account branch from 3dedb0c to 4409e65 Compare December 3, 2024 20:54
@HonzaR HonzaR changed the base branch from account-uuids to feature-2.2.7 December 3, 2024 21:13
@HonzaR HonzaR requested a review from str4d December 3, 2024 21:14
@HonzaR
Copy link
Contributor Author

HonzaR commented Dec 4, 2024

@Milan-Cerovsky, we're ready for review here. I moved the #1640 related changes into the PR and left only #1632 related changes in this PR. Please take a look.

@HonzaR HonzaR force-pushed the 1632-remove-default-account branch from 5d8cd90 to 426f9d2 Compare December 4, 2024 13:33
The rest of the changes (tests changes) will be used by 1640 though
@HonzaR HonzaR force-pushed the 1632-remove-default-account branch from 426f9d2 to 2f4ac4c Compare December 4, 2024 13:46
Copy link
Contributor

@str4d str4d left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

utACK 2f4ac4c. I did not closely review the changes to the demo app.

PR should be squash-merged to get rid of the added-then-removed UUID changes from the history.

@str4d str4d merged commit a744a67 into feature-2.2.7 Dec 4, 2024
9 of 12 checks passed
@str4d str4d deleted the 1632-remove-default-account branch December 4, 2024 15:55
HonzaR added a commit that referenced this pull request Dec 17, 2024
* [#1632] Refactor `Account.DEFAULT` (#1645)

* [#1632] Remove `Account.DEFAULT`

* Update Account related APIs

* Refactor balances APIs

* Adopt `getAccounts` in fragment-based Demo app

We have deprecated the old Fragment-based Demo app. See #973. So, the purpose of these changes is purely the buildability of the new Compose-based Demo app.

* Add init to `JniUnifiedSpendingKey.kt`

* Update deprecated Fragment-based Demo app

This part of the Demo app will be removed as part of #973

* Remove deprecated functions from Synchronizer

* Update WalletSnapshot and WalletVM APIs in Demo

+ necessary fixtures changes

* Update newer Compose-based Demo app

* Hide `Synchronizer.createAccount` form public API

As it was, as making it public could bring more requirements on our multi-account support in version 1

* Add all accounts flow API

* Refactor AccountFixture

- We deduplicated the fixture across the related modules and their tests
- Documentation added

* Fix `fetchUtxos` error (code 14)

- Closes #1648
- This also impacts SDK’s ability to recover from loss of internet connection
- Changelog updated

* Switch from ZIP 32 account indices to UUID account identifiers (#1640)

* Switch from ZIP 32 account indices to UUID account identifiers

* Rename TransactionRecipient.Account

To emphasize the distinction between Account and TransactionRecipient.Account

* Fix `Backend.createAccount` API parameters

* Add `importAccountUfvk` to the Rust backend.

* Propagate accountName and keySource across SDK

* Propagate new importAccount across SDK

* Wrap createAccount setup information

* Wrap importAccount setup information

* Add `Zip32AccountIndex` wrapper

* Update key source parameter

* Remove account from `UnifiedSpendingKey`

* Fix `importAccountByUfvk` API

* Refactor Account.accountUuid to wrapper class

So we can easily keep it typesafe and compare it to each other

* Add `JniAccountUsk`

* Add `seedFingerprint` and `zip32AccountIndex`

To public API `importAccountUfvk`

* Transactions by account UUID

* Refactor default account creation

* Migrate to Rust crate revision with bugfixes to account UUID migration

* Refactor inputs of `importAccountUfvk`

* Use `FirsClassByteArray` for `seed` parameter

---------

Co-authored-by: Honza <[email protected]>
Co-authored-by: Kris Nuttycombe <[email protected]>
Co-authored-by: Honza Rychnovský <[email protected]>
Co-authored-by: Daira-Emma Hopwood <[email protected]>

* Remove unused `TransactionEncoder` functions (#1660)

* Resolve [#1640] review comments

* `Account` documentation fix

* Make `AccountPurpose.Spending` args not null

As they now live under `AccountPurpose.Spending` where we need them not null
+ `AccountImportSetup` doc fix

* Replace `bytes` with `usk` in `AccountUsk`

* Change test name

* Feature/proposal to pczt (#1647)

* Migrate to latest revision of Zcash crates

* Integrate PCZT APIs into the Android SDK

* Fix `Backend.createPcztFromProposal` parameter

* Add Synchronizer side of PCZT logic

* Add `getAccountForUfvk`  method to Rust backend & fix key derivation null issue. (#1656)

* Add `getAccountForUfvk` method to the FFI.

* Only decode key derivation metadata when creating a count with `Spending` purpose.

Also, ensure that a spending account can still be created without providing
key derivation metadata.

* Update to `librustzcash` revision `205d4c930319b7b6d24aeb4efde69e9b4d1b6f7b`

* Add the new `getAccountForUfvk` to `TypesafeBackend`

* Update `FakeRustBackend`

---------

Co-authored-by: Honza <[email protected]>

* Remove unused `TransactionEncoder` functions (#1660)

* Resolve [#1640] review comments

* `Account` documentation fix

* Make `AccountPurpose.Spending` args not null

As they now live under `AccountPurpose.Spending` where we need them not null
+ `AccountImportSetup` doc fix

* Replace `bytes` with `usk` in `AccountUsk`

* Change test name

* Testnet Synchronizer test fix

* Detekt warning

* Changelog update

---------

Co-authored-by: Jack Grigg <[email protected]>
Co-authored-by: Honza <[email protected]>
Co-authored-by: Honza Rychnovský <[email protected]>

* Peformance optimizations

* Revert "Peformance optimizations"

This reverts commit 68de6ae.

* PCZT support follow-ups (#1663)

* Rename exception

* Add sapling param fetching to new KS-related fun

* Add dedicated clone PZCT function

* Add `Synchronizer.Status.INITIALIZING`

For wallets to know that accounts and other APIs are not ready yet

* [#1665] Checkpoints update

Closes #1665

* Bump lib version to 2.2.7

* Migrate to the published Zcash crate releases including PCZT v1 (#1664)

Co-authored-by: Honza <[email protected]>

---------

Co-authored-by: Jack Grigg <[email protected]>
Co-authored-by: Kris Nuttycombe <[email protected]>
Co-authored-by: Daira-Emma Hopwood <[email protected]>
Co-authored-by: Kris Nuttycombe <[email protected]>
Co-authored-by: Milan Cerovsky <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants