-
Notifications
You must be signed in to change notification settings - Fork 43
Merge release-v0.4 branch #342
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
Changes from all commits
50b7f12
f006458
8d767aa
97f142d
59f4f51
3166a0b
32bf966
c1f65ba
c027469
9b1b37e
e8c8209
bf41704
7ac7cee
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
This file was deleted.
This file was deleted.
This file was deleted.
This file was deleted.
This file was deleted.
This file was deleted.
This file was deleted.
This file was deleted.
This file was deleted.
This file was deleted.
Uh oh!
There was an error while loading. Please reload this page.
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.
Don't treat every
finalizeUnwraprevert as “already finalized”.Now that wrappers are only validated at the interface boundary, this generic
catchis too broad. A real unwrap failure can still fall through to_executeRouteafter only checking the proof, even though this batch may never have received its underlying. The fallback path should only be used once unwrap finalization is known to have happened for this batch; otherwise the revert should bubble.🤖 Prompt for AI Agents
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.
Made an issue #343 to track this. We may not be able to do further introspection.
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.
@arr00Understood — thanks for opening#343to track this. You're right that Solidity'stry/catchhas limited granularity; decoding custom errors from acatch (bytes memory)block is possible but brittle, and there may not be a reliable sentinel to distinguish "already finalized" from other failure modes depending on how the wrapper implementsfinalizeUnwrap. Happy to revisit the options when that issue is worked on.🧠 Learnings used