-
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(governance): some governance invitations use proposal patterns #7041
Conversation
fce8418
to
ef35a91
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.
I commented on the ones I know.
// Or should this be more like the AdjustBalancesProposalShape in | ||
// vaultFactory, that allows both records to have both properties? |
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 so... but only because I don't see a case where you would want to give both collateral and debt-brand, or want both. Why is that allowed in vaultFactory?
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 requirement for VaultFactory AdjustBalances is that you can "give" or "want" without specifying the other.
I don't know either of a good use case for giving the same brands as you're wanting, but there's also not a strong reason to forbid that and allowing it makes the shape simpler to implement the above requirement.
Doesn't the StakeFactory have the same requirement? i.e. that you can specify one and the other is implied by your staked holdings. If so we lack test coverage for that case because this shape isn't throwing.
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 can't tell whether this is redundant with what @turadg said, but I want to be explicit:
with VF AdjustBalances, you can give both or want both or give one and want the other. I don't think it ever makes sense to have the same keyword in both give and want.
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.
If so we lack test coverage for that case ...
That's where my mind went too.
I'm not sure I can justify the time to swap in the relevant context for this just now.
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 goal for this PR is to express with patterns at least the restrictions that were expressed by assertProposalShape
and similar, but still be unrestrictive enough to allow everything we should be allowing. So, based on what I think I understood of the above comments, I did revise this pattern to be like the AdjustBalancesProposalShape
from VF, that is more accepting.
PTAL and let me know if I misunderstood. Leaving this Conversation unresolved until I hear back.
packages/inter-protocol/src/vaultFactory/liquidateIncrementally.js
Outdated
Show resolved
Hide resolved
fdcf70d
to
933d539
Compare
// Or should this be more like the AdjustBalancesProposalShape in | ||
// vaultFactory, that allows both records to have both properties? |
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 goal for this PR is to express with patterns at least the restrictions that were expressed by assertProposalShape
and similar, but still be unrestrictive enough to allow everything we should be allowing. So, based on what I think I understood of the above comments, I did revise this pattern to be like the AdjustBalancesProposalShape
from VF, that is more accepting.
PTAL and let me know if I misunderstood. Leaving this Conversation unresolved until I hear back.
zcf.makeInvitation( | ||
seatx => helper.closeHook(seatx), | ||
'CloseVault', | ||
undefined, | ||
StakeFactoryCloseProposalShape, | ||
), |
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.
Seems annoyingly similar to the zcf.makeInvitation
call in stakeFactoryKit
function makeCloseInvitation
. As a result, the proposalShape used here is annoyingly like the one used there. Can we consolidate both?
Leaving Conversation unresolved until I hear back.
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.
seems like they could be unified. What's the obstacle? The factory has the branded amounts. Can the kit get them from there? Is there an obstacle to the Kit making the branded amounts itself?
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.
@Chris-Hibbert I recall we discussed this, but I no longer remember where we landed. Do you?
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 remember the conversation. Shall we try again?
packages/inter-protocol/src/vaultFactory/liquidateIncrementally.js
Outdated
Show resolved
Hide resolved
995f366
to
05b90ff
Compare
601f312
to
31551ac
Compare
Datadog ReportBranch report: ✅ |
b0bd0e0
to
1b7cc36
Compare
1b7cc36
to
7570893
Compare
Datadog ReportBranch report: ❌ ❌ Failed Tests (1)
|
7570893
to
2b38651
Compare
2b38651
to
f56aa87
Compare
342e10f
to
ae5ea19
Compare
Reviewers, Enough has changed that it is worth asking afresh: What's needed for me to move this forward? Because
I would like to make progress on this. But no great urgency. |
If some cases remain problematic, I'd rather just postpone those to a later PR and make progress now on the non-problematic ones. Thanks. |
The emerging norm is to have upgrade tests for any contracts deployed in production; in particular, Pegasus is not (yet) in production, so landing that seems un-problematic. I think For the helper functions, I'd like to see them traced back to any production bundles that they might appear in. |
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'm not sure about landing changes to committee.js without at least a scheduled issue for upgrade testing. @turadg ?
Given the low urgency of landing this and that we have upgrade-12 scheduled, I'd request such a test be included in this PR before considering landing it.
Please include this in an "Upgrade considerations" section in the main PR description. |
Done |
What if I postponed the committee.js changes to a later PR? What if I postponed all the packages/governance changes to a later PR? |
ae5ea19
to
4cd5f10
Compare
Separating governance might do it. Would have to check whether the zoe changes affect any production bundles too. |
4cd5f10
to
9372909
Compare
9372909
to
b023677
Compare
Zoe and Pegasus cases extracted to #8268 , leaving only the governance cases here. |
b023677
to
2df9334
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.
113fc49
to
a620aaf
Compare
a620aaf
to
1a0db7d
Compare
Start replacing uses of the deprecated
assertProposalShape
withmakeInvitation
s direct support for proposalShape patterns. This provides better protection for contracts against malformed offers. When an offer's proposal violates the contract's required proposalShape pattern, it is rejected in Zoe and the contract never even sees the malformed offer.This PR is somewhat empirical, revising the provided proposal patterns so that they were tighter than the
assertProposalPattern
call it replaced, while still passing all tests. For each modified contract, it would be good for someone who knows the meaning of the contract to do a sanity check on the proposalShape pattern.One particular way these patterns could be tighter, to protect the contract from seeing more malformed offers, is to use the amountShape specific to the brand the contract is willing to accept in that position. I skipped that additional work, leaving a TODO there instead. Reviewers, if you know what brand-specific amountShape I should use in any such case, please let me know.
Upgrade considerations
We definitely need to think hard about whether this PR introduces any representation changes that create an upgrade issue. The proposal shapes that we're less worried about were extracted into #8268 , leaving only some governance cases here.