Skip to content
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

Delete pending cap when removing a market #348

Merged
merged 19 commits into from
Jan 2, 2024
Merged

Conversation

@Jean-Grimal Jean-Grimal requested review from a team, adhusson, Rubilmax, QGarchery, MerlinEgalite and MathisGD and removed request for a team December 13, 2023 09:45
test/forge/MarketTest.sol Outdated Show resolved Hide resolved
Co-authored-by: Romain Milon <rmilon@gmail.com>
Signed-off-by: Jean-Grimal <83286814+Jean-Grimal@users.noreply.github.com>
test/forge/MarketTest.sol Outdated Show resolved Hide resolved
Co-authored-by: Romain Milon <rmilon@gmail.com>
Signed-off-by: Jean-Grimal <83286814+Jean-Grimal@users.noreply.github.com>
MerlinEgalite
MerlinEgalite previously approved these changes Dec 13, 2023
@MathisGD
Copy link
Contributor

to me we should more prevent any cap setting when the market is being removed

@MerlinEgalite
Copy link
Contributor

to me we should more prevent any cap setting when the market is being removed

indeed it sounds good

@Rubilmax
Copy link
Contributor

Rubilmax commented Dec 15, 2023

to me we should more prevent any cap setting when the market is being removed

There's one thing for sure is that this PR does not 100% fix the issue raised: even if the pending cap is deleted, it can be submitted again afterwards
Am I right?

In which case I believe reverting when removableAt != 0 in _setCap is better

Copy link
Contributor

@Rubilmax Rubilmax left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See above

@MerlinEgalite
Copy link
Contributor

to me we should more prevent any cap setting when the market is being removed

There's one thing for sure is that this PR does not 100% fix the issue raised: even if the pending cap is deleted, it can be submitted again afterwards Am I right?

In which case I believe reverting when removableAt != 0 in _setCap is better

which would be fixed by #353 right?

@Jean-Grimal
Copy link
Contributor Author

to me we should more prevent any cap setting when the market is being removed

There's one thing for sure is that this PR does not 100% fix the issue raised: even if the pending cap is deleted, it can be submitted again afterwards Am I right?
In which case I believe reverting when removableAt != 0 in _setCap is better

which would be fixed by #353 right?

I don't think so,

@MathisGD @Rubilmax should I make the change in this PR ?

@@ -355,6 +355,7 @@ contract MetaMorpho is ERC4626, ERC20Permit, Ownable2Step, Multicall, IMetaMorph
}

delete config[id];
delete pendingCap[id];
Copy link
Contributor

@QGarchery QGarchery Dec 22, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[optional] I realize now that these changes (both config[id] and pendingCap[id]) may be difficult to follow offchain with events. This requires to do the difference of sets to know which markets were removed. Maybe emitting an event here would be nice for offchain purposes

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor

@QGarchery QGarchery left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's one thing for sure is that this PR does not 100% fix the issue raised: even if the pending cap is deleted, it can be submitted again afterwards
Am I right?

I thought it would need happen after the removal of the market (or otherwise it gets deleted), which sounds like a wanted behavior.

But actually it could happen that the pending cap is accepted first in 2 cases:

  • the removal of the market is done slowly after its timelock, for example a couple of blocks slip by and the pending cap timelock is reached
  • the timelock is reduced, and a new pending cap is submitted before the end of the removal of the market timelock

So in the end I agree that we should enforce stricter rules on the pending cap

src/MetaMorpho.sol Outdated Show resolved Hide resolved
src/MetaMorpho.sol Outdated Show resolved Hide resolved
MerlinEgalite
MerlinEgalite previously approved these changes Dec 28, 2023
src/MetaMorpho.sol Outdated Show resolved Hide resolved
@StErMi
Copy link

StErMi commented Dec 31, 2023

Should you also delete any pending cap proposal when the market is removed from the withdrawal queue?

@MerlinEgalite
Copy link
Contributor

MerlinEgalite commented Dec 31, 2023

Should you also delete any pending cap proposal when the market is removed from the withdrawal queue?

I don't think so since pendingCap[id].validAt is checked before. If this timestamp is null then the pending cap is null as well.

QGarchery
QGarchery previously approved these changes Dec 31, 2023
Copy link
Contributor

@QGarchery QGarchery left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds good, it fixes this comment because now the pending cap prevents removal (which means there are no problem of ordering market removal and updating caps)

src/MetaMorpho.sol Outdated Show resolved Hide resolved
@MathisGD MathisGD dismissed stale reviews from QGarchery and MerlinEgalite via e95d7cc January 2, 2024 06:58
MathisGD
MathisGD previously approved these changes Jan 2, 2024
Copy link
Contributor Author

@Jean-Grimal Jean-Grimal left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@MerlinEgalite MerlinEgalite merged commit bcebf0f into post-cantina Jan 2, 2024
6 checks passed
@MerlinEgalite MerlinEgalite deleted the fix/issue-491 branch January 2, 2024 10:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants