-
Notifications
You must be signed in to change notification settings - Fork 8
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
2.2.1 Release #633
2.2.1 Release #633
Conversation
], | ||
remove: [], | ||
skipSelectors: {}, | ||
facetsToInit: {}, | ||
facetsToInit: { |
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 we are adding new interfaceIds here I believe migrations scripts should also be responsible for removing old facets interfaceIds from diamond-supported interfaces.
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.
would be good to validate this in upgrade tests 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.
There are two things:
- first we have "initialized interfaces", which are stored in
ps.initializedInterfaces
and are used by theonlyUninitialized
modifier. This value can currently be set to true only by callinginitialize
, that's why I added them here. If I didn't, well, I don't think anything bad could happen. It's more of a consistency thing. This value is a bit peculiar since it can only be turned to true and not back to false (currently). I'm happy to discuss if we even need this initialization pattern or if should we simply deprecate it. Since initialize should never be registered as a diamond method, I don't see a security risk there if we omitonlyUninitialized
from facets in the upcoming releases. - Then we also have "supported Interfaces" which are stored in
ds.supportedInterfaces
and are used when someone querieserc165.supportsInterface
. The upgrade script already passes a list ofinterfaceIds
to add and remove toProtocolInitializationHandlerFacet
when the diamond cut is made. So no need to do any changes to those scripts. But yeah, it might be worth adding that to generic upgrade tests, since I assume most upgrades will change at least some interfaces.
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.
IMO modifiers should be used for security reasons and if this modifier is not prevent anything bad from happening I vote for removing
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.
added an issue just to not ended up loosing this discussion as I'm going to merge this PR
2.2.0 fix metaTransaction initialization
Release 2 2 0
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 am happy with this.
Also includes the changes for upgrade 2.1.0->2.2.0