-
Notifications
You must be signed in to change notification settings - Fork 229
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
feat(smartWallet): defer deposits until purse available #6172
Conversation
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.
get
throws on our collections, no?
(reusing the standard name with different behavior was... an odd choice, IMO)
const amountPKeywordRecord = objectMap(paymentKeywordRecord, payment => | ||
E(purseForBrand(payment.getAllegedBrand())).deposit(payment), | ||
const amountPKeywordRecord = objectMap(payouts, paymentRef => | ||
E.when(paymentRef, payment => depositFacet.receive(payment)), |
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.
👍 good idea to re-use the depositFacet
*/ | ||
async receive(payment) { | ||
/** @type {State} */ | ||
const { brandPurses } = this.state; | ||
const { brandPurses, paymentQueues: queues } = this.state; | ||
const brand = await E(payment).getAllegedBrand(); | ||
const purse = brandPurses.get(brand); |
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 get will throw rather than returning undefined, no?
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.
yes good catch! I added a unit test for regression and it caught a missing harden too.
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.
thanks for the unit test
supporting #6157
Description
Some brands aren't available when a payments to the deposit facet. In this case we now hold the payments in a queue and when the purse is available we deposit all of them.
The payouts handler now uses the deposit facet to get the same feature. It also attempts each payout separately instead of the previous behavior of blocking until all payments were available.
Security Considerations
Deposits are unpermissioned so queuing them opens an attack to grow the queue unbounded. The collections are durable which should mitigate RAM consumption. If there are more problems in practice the queue size can be capped. I considered doing that in this PR but considered a worse vulnerability is for an attacker to fill the queue of a wallet and prevent legitimate deposits.
Documentation Considerations
--
Testing Considerations
--