-
Notifications
You must be signed in to change notification settings - Fork 212
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
fix(walletFactory): move upgrading check before baggage is populated #8322
Conversation
It works, no bridge handler error when starting the chain and I'm able to sign transactions via keplr. Thanks for the fix! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fix looks good. Glad the branch unblocks Kryha.
Requesting changes for code formatting and a regression test. An alternative is to spec and schedule a design that prevents this sort of error.
@@ -142,6 +142,7 @@ export const makeAssetRegistry = assetPublisher => { | |||
* @param {import('@agoric/vat-data').Baggage} baggage | |||
*/ | |||
export const prepare = async (zcf, privateArgs, baggage) => { | |||
const upgrading = baggage.has('walletsByAddress'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👌
Any ideas for catching the temptation in the future to move such a check?
@Chris-Hibbert WDYT of the zcf providing this sort of info? Perhaps even incarnationNumber?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think our mock bridge is lax about registration. So I expect that if we make it more strict we could reproduce this in a unit test.
2525885
to
b82063a
Compare
oh no! vs-code has gone rogue! format-on-save was my friend but now it's my enemy. |
handler = newHandler; | ||
}, | ||
setHandler(newHandler) { | ||
handler || Fail`Handler not set`; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
eslint giving an error. would it work to use the check style on line 70?
if (!handler) {
Fail`No handler for ${bridgeId}`;
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh. I suppose that would have been good for consistency.
I just pushd a fixup with !!handler || Fail...
though.
The `baggage.has('walletsByAddress')` check has to come before the `provideDurableMapStore(baggage, 'walletsByAddress')` call.
... and handler already set
b82063a
to
8f08b29
Compare
…8322) * fix(walletFactory): move upgrading check before baggage is populated The `baggage.has('walletsByAddress')` check has to come before the `provideDurableMapStore(baggage, 'walletsByAddress')` call. * test(smart-wallet): fake bridge manager detects handler not set ... and handler already set * fixup! test(smart-wallet): fake bridge manager detects handler not set
…8322) * fix(walletFactory): move upgrading check before baggage is populated The `baggage.has('walletsByAddress')` check has to come before the `provideDurableMapStore(baggage, 'walletsByAddress')` call. * test(smart-wallet): fake bridge manager detects handler not set ... and handler already set * fixup! test(smart-wallet): fake bridge manager detects handler not set
closes: #8321
refs: #8311
Description
The
baggage.has('walletsByAddress')
check has to come before theprovideDurableMapStore(baggage, 'walletsByAddress')
call.Testing Considerations
Meanwhile, @carlos-kryha , if you find a moment to try this fix, please let us know how it goes.
Security / Scaling / Documentation Considerations
none
Upgrade Considerations
This fixes the non-upgrade case, i.e. the 1st incarnation case.