chore: Update initialize in GaslessRelayer#3096
chore: Update initialize in GaslessRelayer#3096dijanin-brat wants to merge 14 commits intomasterfrom
Conversation
dijanin-brat
force-pushed
the
dijanin-brat/fixInitializeGaslessRelayer
branch
from
9632ccf to
68c4f25
Compare
dijanin-brat
requested review from
bmzig,
dohaki,
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: 68c4f25760
ℹ️ 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".
| // If there's already known state for this deposit nonce, skip it. | ||
| return !isDefined(this.messageState[depositKey]); | ||
| const rawState = this.messageState[depositKey]; | ||
| return !isDefined(rawState) || !terminalStates.includes(rawState); |
There was a problem hiding this comment.
The messageFilter no longer checks whether a deposit's originChainId is one of this relayer's configured origin chains, so out-of-scope API messages now pass through as long as they are not in a terminal state. In environments where the gasless API returns multiple origins, this can drive evaluateApiSignatures into getPeripheryContract(originChainId) / fill paths with undefined chain wiring, causing runtime failures or repeated failed tx attempts instead of safely ignoring unsupported chains.
Useful? React with 👍 / 👎.
src/gasless/GaslessRelayer.ts
Outdated
| if (hasDeposit && hasFill) { | ||
| this._setState(depositKey, MessageState.FILLED); | ||
| } else if (hasDeposit && !hasFill) { | ||
| this._setState(depositKey, MessageState.FILL_PENDING); |
There was a problem hiding this comment.
updateObserved now marks recovered deposits as FILL_PENDING but does not retain the on-chain FundsDeposited payload, so resumed processing enters FILL_PENDING with deposit undefined and falls back to synthetic data. Under refund-flow test mode (outputAmount == MAX_UINT_VAL), this path skips the deposit.outputAmount short-circuit in the deposit branch and can spin indefinitely waiting for a fill that should never occur, because the state machine was bootstrapped into FILL_PENDING without the concrete deposit object.
Useful? React with 👍 / 👎.
|
@codex Please re-review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 2575d2bf74
ℹ️ 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".
src/gasless/GaslessRelayer.ts
Outdated
| if (terminalStates.includes(getState())) { | ||
| return; |
There was a problem hiding this comment.
Allowing processDepositMessage to continue from any non-terminal state here enables re-entry for DEPOSIT_SUBMIT/DEPOSIT_CONFIRM/FILL_PENDING, and this combines badly with polling via setInterval in src/utils/Tasks.ts (which does not wait for prior runs to finish). When a single deposit takes longer than API_POLLING_INTERVAL (default 1s) to confirm/fill, overlapping poll iterations can process the same deposit simultaneously, leading to duplicate initiateDeposit/initiateFill submissions and state races.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
nice catch!
@codex can you re-review this
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: c09d0f4149
ℹ️ 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".
src/gasless/GaslessRelayer.ts
Outdated
| let fillImmediate = | ||
| !isSwap && | ||
| this.fillImmediate( | ||
| { originChainId, destinationChainId, outputToken, outputAmount, exclusivityParameter }, | ||
| spokePool |
There was a problem hiding this comment.
fillImmediate is computed before the startup state bootstrap, so messages that already have an observed origin deposit (hasDeposit) can enter FILL_PENDING with fillImmediate=true. In that case, a successful fill transitions to DEPOSIT_CONFIRM as if this run submitted a deposit, and if _findDeposit misses (e.g., lookback edge or transient RPC miss) the state falls back to DEPOSIT_SUBMIT, re-attempting an already-spent authorization. This regression affects restart recovery for pre-existing unfilled deposits; the immediate flag should be set only when the handler actually goes through the INITIAL -> DEPOSIT_SUBMIT path.
Useful? React with 👍 / 👎.
dijanin-brat
changed the title
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 1514101b6c
ℹ️ 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".
| } else if (hasFill) { | ||
| initialState = MessageState.DEPOSIT_SUBMIT; |
There was a problem hiding this comment.
If a fill is observed but the matching origin FundsDeposited event is not (for example, origin events fall outside depositLookback or the origin RPC misses logs), this branch sets the message to DEPOSIT_SUBMIT, which immediately calls initiateDeposit() again. In that recovery scenario the relay is already filled, so re-entering the deposit path can trigger duplicate submit attempts/reverts and unnecessary gas spend; the hasFill path should short-circuit to a terminal state instead of resubmitting.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
we should be able to submit a Gasless deposit just once, so if the deposit is already submitted the next time we try to send it it will fail.
dijanin-brat
changed the title
1 participant
No description provided.