-
Notifications
You must be signed in to change notification settings - Fork 208
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
4484 multitenant smart wallet #5721
Conversation
d807b03
to
ae2027b
Compare
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.
Looks good.
It would look better with tests for multiple addresses; I leave that up to you.
*/ | ||
export const provideAsync = async (mapStore, key, makeValue) => { | ||
if (!mapStore.has(key)) { | ||
mapStore.init(key, await makeValue(key)); |
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.
this goes against No Nested Await. Is there any particular justification?
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.
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.
The introduction of the pending
Map doesn't seem equivalent to this. If it's essential, that seems to mean the nested await form was buggy. Anyway... it looks workable, and I'm content that #5728 is where we deal with it definitively.
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.
The introduction of the pending Map doesn't seem equivalent to this
Right, I wasn't clear. The nested await went away as a side effect of the refactoring to makeAtomicProvider
. The need for that function was because of a race condition I encountered when testing multiple wallets. Thanks for suggesting it!
}, | ||
}) => { | ||
const STORAGE_PATH = 'wallet'; | ||
|
||
const storageNode = await getChildNode(chainStorage, STORAGE_PATH); | ||
const marshaller = E(board).getPublishingMarshaller(); | ||
const { creatorFacet } = await E(zoe).startInstance( |
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.
FYI, dropping the admin facet here is not great; but we have plans elsewhere to address it: #4548 (comment)
return makeChainStorageRoot(toStorage, 'swingset', 'mockChainStorageRoot'); | ||
}; | ||
|
||
const mockAddress1 = 'mockAddress1'; |
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.
how about testing 2 or 3 addresses / wallets?
d217901
to
80f642b
Compare
ae2027b
to
e0309aa
Compare
e0309aa
to
57eac62
Compare
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.
Part of #4484. This doesn't do everything described in that ticket ...
really? ah. indeed... virtualization / durability.
refs: #4484
Description
Part of #4484. This doesn't do everything described in that ticket so I'm leaving it to the ticket author to decide what's left, if anything.
Security Considerations
Shared contract amongst all on-chain wallets. Potential DoS attack.
Documentation Considerations
--
Testing Considerations
New tests