-
Notifications
You must be signed in to change notification settings - Fork 214
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
chore: fusdc recovery paths #10659
chore: fusdc recovery paths #10659
Conversation
zcf.atomicRearrange( | ||
harden([[borrowSeat, repaySeat, amountKWR, returnAmounts]]), | ||
); |
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 don't think we need try/catch here since we are protected by the borrower.repay
interface guard.
LMK if that thinking is off base and/or a code comment is warranted,
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 interface guard doesn't prevent calling this function with a borrowSeat
that doesn't have enough USDC.
Check isGTE(borrowSeat.getAmountAllocated('USDC'), amountToRepay)
before calling atomicRearrange
.
And I think we need a try/catch here exactly as much as in the other functions that reallocate. I can see arguments either way (the commit phase is synchronous for all of them), but I don't see how this one should be different.
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.
re-reading Prepare / Commit, the try
/ catch
is only in order in case the commit phase is not atomic.
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.
Check isGTE(borrowSeat.getAmountAllocated('USDC'), amountToRepay) before calling atomicRearrange
Agree, added.
re-reading Prepare / Commit, the try / catch is only in order in case the commit phase is not atomic.
I think this means we should remove the zcf.shutdownWithFailure(reason);
's in liquidity-pool? If yes, please see 1d8c44e
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.
please remove all the shutdowns; leave >= 1 UNTIL #10684 comment.
In some cases, the try
part of the commit has multiple synchronous steps. Part of me was thinking of that as atomic, since it's all 1 turn. But it's not atomic. Regardless, recent discussion suggests removing all shutdownWithFailure
calls UNTIL #10684.
see 1d8c44e
I tried; no joy.
db3ced7
to
4db6510
Compare
Deploying agoric-sdk with Cloudflare Pages
|
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 don't see any correctness problems, but I'm not ready to approve without some discussion.
// TODO #10510 (comprehensive error testing) determine | ||
// course of action here | ||
onRejected(error, { tmpSeat, advanceAmount, ...restCtx }) { | ||
// we don't expect this to be a common failure. if it happens, return funds to LP |
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.
Is how common it is relevant? We're talking user funds here, after all.
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 point, updated the comment with "how"
'TODO live payment on seat to return to LP', | ||
q(tmpSeat).toString(), | ||
'⚠️ deposit to localOrchAccount failed, attempting to return payment to LP', | ||
q(error).toString(), |
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.
why stringify the error? why not let log
do that?
this will lose stack info, 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.
Good point, done
* If something fails during advance, return funds to the pool. | ||
* | ||
* @param {ZCFSeat} borrowSeat | ||
* @param {{ USDC: Amount<'nat'>}} amountKWR |
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.
Is there any reason to make this a record?
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.
Only in as much localTransfer
/withdrawToSeat
and their ~counterparts depositToSeat
, withdrawToSeat
expect amountKWR
.
I agree this could be dropped. If we did, I would do the same in borrow
. Let me know if we should make this change.
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, I think we should.
I'm OK with leaving it if it would cost you another ci round trip.
zcf.atomicRearrange( | ||
harden([[borrowSeat, repaySeat, amountKWR, returnAmounts]]), | ||
); |
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 interface guard doesn't prevent calling this function with a borrowSeat
that doesn't have enough USDC.
Check isGTE(borrowSeat.getAmountAllocated('USDC'), amountToRepay)
before calling atomicRearrange
.
And I think we need a try/catch here exactly as much as in the other functions that reallocate. I can see arguments either way (the commit phase is synchronous for all of them), but I don't see how this one should be different.
console.log('LpBorrowFacet.borrow called with', amounts); | ||
mockBorrowerFacetCalls.push(['borrow', seat, amounts]); |
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.
given that we're now actually consuming the args and checking them, is logging them still useful?
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.
Agree, removed
borrowCall[1], | ||
'same temp borrowSeat is supplied to LP during repay', | ||
); | ||
t.deepEqual(repayCall[2], borrowCall[2], 'advance amount is returned to LP'); |
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.
check repayCall[2]
against some literal data? maybe the value of an amount?
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 feedback, done. Refactored this test a bit as it was confusing. Also added alerts if returnToPool
fallback fails
@@ -88,6 +88,10 @@ export const prepareLiquidityPoolKit = (zone, zcf, USDC, tools) => { | |||
SeatShape, | |||
harden({ USDC: makeNatAmountShape(USDC, 1n) }), | |||
).returns(), | |||
repay: M.call( |
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.
using the same name (repay
) with different semantics (sometimes fees, sometimes without) is asking for trouble, IME.
maybe...
repay: M.call( | |
returnToPool: M.call( |
repay: M.call( | |
repayFailed: M.call( |
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.
Noted, updated to returnToPool
4db6510
to
85ce625
Compare
- only use `zcf.shutdownWithFailure` in a catch block around `atomicRearrange()` and when the commit phase is _not_ atomic - see #10659 (comment) - note: try/catch/finally remains for `borrow()` and `deposit()` so we can exit seats
85ce625
to
1d8c44e
Compare
- only use `zcf.shutdownWithFailure` in a catch block around `atomicRearrange()` and when the commit phase is _not_ atomic - see #10659 (comment) - note: try/catch/finally remains for `borrow()` and `deposit()` so we can exit seats
1d8c44e
to
a8a0cf1
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.
Good stuff.
I feel some obligation to give the whole thing a fresh look, but I don't have energy for that today, so you might want to stand by for more eyes.
- wait until #10684, where we can terminate an incarnation without terminating the contract - see #10659 (comment) - note: try/catch/finally remains for `borrow()` and `deposit()` so we can exit seats
a8a0cf1
to
81517e2
Compare
t.deepEqual(inspectLogs(1), [ | ||
'txHash already seen:', | ||
'0xc81bc6105b60a234c7c50ac17816ebcd5561d366df8bf3be59ff387552761702', | ||
const [, , ...remainingLogs] = inspectLogs(); |
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.
TIL array destructuring doesn't have to name elements
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 I relearned that yesterday. Same with assignment while destructuring. JavaScript is fun 🙂
7fac172
to
50c1bd1
Compare
closes: #10624
Description
zoeTools.localTransfer
during FUSDC Advance flow by returning funds to LPzoeTools.withdrawToSeat
failure in.disperse()
zcf.shutdownWithFailure()
in catch blocks aroundzcf.atomicRearrange
. This is only necessary when commits are not atomic.Security Considerations
Scaling Considerations
N/A
Documentation Considerations
N/A
Testing Considerations
Includes a unit test that ensures the advancer performs the expected calls after
zoeTools.localTransfer
fails.Does not include unit tests for the new liquidity pool
borrower.returnToPool
as those have been deemed too expensive. The risk here seems low as the call is effectively passed through torepayer.repay
, which has tests, modulo the KWR arrangement which is protected by the interface guard.Upgrade Considerations
None, FUSDC is unreleased.