Conversation
Signed-off-by: Ihor Farion <ihor@umaproject.org>
Signed-off-by: Ihor Farion <ihor@umaproject.org>
Signed-off-by: Ihor Farion <ihor@umaproject.org>
Signed-off-by: Ihor Farion <ihor@umaproject.org>
Signed-off-by: Ihor Farion <ihor@umaproject.org>
Signed-off-by: Ihor Farion <ihor@umaproject.org>
Signed-off-by: Ihor Farion <ihor@umaproject.org>
Signed-off-by: Ihor Farion <ihor@umaproject.org>
|
|
||
| // TODO: perhaps this warrants a rename. Since `msg.sender` here does not get recorded as `submitter`. Submitter | ||
| // TODO: is only the one doing `submitWithData` or `fill`. Think about naming | ||
| function submit(Order calldata order, TypedData calldata orderFunding) external nonReentrant { |
There was a problem hiding this comment.
so a user can use this function to pre-fill an order?
There was a problem hiding this comment.
You mean pre-fund? Yeah exactly
This can be user-facing or
auto-finalization-facing (e.g. in OFT when there's no obvious submitter to provide extra submitterData)
Signed-off-by: Ihor Farion <ihor@umaproject.org>
Signed-off-by: Ihor Farion <ihor@umaproject.org>
grasphoper
requested review from
bmzig,
mrice32,
nicholaspai and
pxrl
as code owners
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 1aa415c0f6
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| uint256 amountToPropagate = _checkRequirements(step, submitter); | ||
| _runFinalAction(orderId, submitter, path.next, step.finalAction, amountToPropagate, s.finalActionValue); |
There was a problem hiding this comment.
When multicallData uses a non-zero fallbackRecipient, _executeMulticall catches inner call failures and attempts to recover by draining orderIn.token, but this function still unconditionally runs _checkRequirements and _runFinalAction afterward. In the common case (minAmount > 0), those later checks revert, which rolls back the earlier drain and defeats the fallback behavior entirely, so failed multicalls still fail atomically instead of honoring the configured fallback recipient.
Useful? React with 👍 / 👎.
2 participants
No description provided.