Conversation
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
6 tasks
Member
Author
|
Superseded by #231, same commit on a branch named after the app branch so determine-e2e-branch picks it up on synonymdev/bitkit-android#1299. |
This file contains hidden or 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
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.
Companion of synonymdev/bitkit-android#1299
Part of synonymdev/bitkit-android#797
@boost_1 - Can do CPFPrestores the wallet from seed, reinstalls, and only then mines the block that confirms the boosted receive. The restored wallet never saw that transaction in the mempool, so on synonymdev/bitkit-android#1299 the confirmation is its first sight of the deposit and the received sheet opens over the screen. The next step isdoNavigationClose(), which fails withelement ("...resourceId("HeaderMenu")") still not displayed after 30000ms.The sheet is correct there: the wallet really did receive a transaction it had not seen before, and the restore has already finished, so neither the restore guard nor the one-hour block-timestamp guard applies. The spec is what needs to change.
This PR:
dismissReceivedPaymentIfShown()totest/helpers/actions.ts, a tolerant wrapper aroundacknowledgeReceivedPayment()that returns false instead of throwing when no sheet appears.@boost_1betweenmineBlocks(1)anddoNavigationClose().The helper is tolerant on purpose: iOS does not notify confirmed-only receives yet (synonymdev/bitkit-ios#455), and neither does Android master, so the same spec has to pass with and without the sheet.
acknowledgeReceivedPaymentIfPresent()could not be reused as is, because it is strict on thelocalbackend that this shard runs on.@boost_2 - Can do RBFalso restores and mines, and is left alone: the block there confirms the outgoing RBF transaction, and the incoming 100k was already confirmed before the restore, so no confirmed-only receive follows the restore. It passes on synonymdev/bitkit-android#1299 today.Not run locally: the change adds one helper call and a helper that only wraps an existing one in try/catch.
test/specs/boost.e2e.tsis prettier-clean;test/helpers/actions.tshad pre-existing prettier warnings before this change and the added block is formatted to the repo config.