fix: align extension storage 'set' and 'observeAll' with pouchdb storage behavior #1597
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
Allure Report
processReports: ✅ test report for a657b3a4
|
mkazlauskas
force-pushed
the
fix/delete-wallet
branch
from
aaf9d67 to
953d550
Compare
mirceahasegan
approved these changes
Dec 16, 2024
mirceahasegan
approved these changes
Dec 17, 2024
…age behavior deleting a wallet does: 1. delete it from repository 2. check remaining wallets, activate if some wallet exists there was a bug where step 2. would find the wallet that was just deleted and try to activate it, because extension storage 'observeAll' emits an slightly later
set()/get() applies toSerializableObject/fromSerializableObject respectively storageChange$ did not, resulting in emitting slightly different objects that were not processed by fromSerializableObject util this broke disabling accounts that were just enabled and possibly some other functionality
mkazlauskas
force-pushed
the
fix/delete-wallet
branch
from
05db09f to
66a958b
Compare
in order to recover from wallet activation bugs for example, a crash after wallet deactivation but before activating another wallet fix: do not explicitly deactivate wallet when switching to another explicitly deactivating will trigger a recovery mechanism that will activate any wallet
mkazlauskas
force-pushed
the
fix/delete-wallet
branch
from
66a958b to
a657b3a
Compare
|
mkazlauskas
added a commit
that referenced
this pull request
Dec 18, 2024
…age behavior (#1597) * fix: align extension storage 'set' and 'observeAll' with pouchdb storage behavior deleting a wallet does: 1. delete it from repository 2. check remaining wallets, activate if some wallet exists there was a bug where step 2. would find the wallet that was just deleted and try to activate it, because extension storage 'observeAll' emits an slightly later * fix: apply fromSerializableObject to objects emitted from storageChange$ set()/get() applies toSerializableObject/fromSerializableObject respectively storageChange$ did not, resulting in emitting slightly different objects that were not processed by fromSerializableObject util this broke disabling accounts that were just enabled and possibly some other functionality * fix: activate any wallet when none is active in order to recover from wallet activation bugs for example, a crash after wallet deactivation but before activating another wallet fix: do not explicitly deactivate wallet when switching to another explicitly deactivating will trigger a recovery mechanism that will activate any wallet
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.
Checklist
Proposed solution
LW-11986
deleting a wallet does:
there was a bug where step 2. would find the wallet that was just deleted and try to activate it, because extension storage 'observeAll' emits slightly later
953d550
LW-11993
set()/get() applies toSerializableObject/fromSerializableObject respectively
storageChange$ did not, resulting in emitting slightly different objects
that were not processed by fromSerializableObject util this broke disabling accounts that were just enabled
and possibly some other functionality
487502c