-
Notifications
You must be signed in to change notification settings - Fork 196
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(cli): function selector lookup #2800
Conversation
🦋 Changeset detectedLatest commit: 4c7bd39 The changes in this PR will be included in the next version bump. This PR includes changesets to release 24 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
2623264
to
95509d2
Compare
selector: worldFunctionSelector, | ||
signature: selectorToSignature[worldFunctionSelector], | ||
systemFunctionSelector, | ||
systemFunctionSignature: selectorToSignature[systemFunctionSelector], |
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.
do we wanna do any sort of throwing or skipping if this doesn't exist? might be easier to track these kinds of issues in the future vs. the stacktrace we were getting in user reports
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 should always exist since the function signature table includes both world and system signatures. We could throw but it would be more like a "if this throws there is a bug in the protocol".
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 reasonable to throw when we suspect a protocol issue than letting this failed with some obscure undefined
error, but not blocking
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.
discussed offline, since the deployer is tied to a protocol version it's fine to assume the protocol behaves as expected here
No description provided.