improve(clients): track upcoming refunds only for configured relayers - #3604
improve(clients): track upcoming refunds only for configured relayers#3604droplet-rl wants to merge 2 commits into
Conversation
The spoke pool running-balance reporter (#3602) was the last consumer that needed all-relayer refund sums from BundleDataApproxClient. Every remaining consumer queries a relayer known at construction time: InventoryClient always queries its own relayer, and the Monitor queries each of its configured monitored relayers. - BundleDataApproxClient now takes the set of relayers to track and skips all other relayers' fills, which also avoids running the per-fill token equivalence lookups for the (majority) untracked fills. - Remove the upcoming-deposits tracking outright: getUpcomingDeposits lost its only consumer in #3602. The serialized BundleDataState shape is unchanged (upcomingDeposits is exported empty) so Redis handover state stays compatible with older/newer relayer versions in both directions; the inventory cache key embeds the relayer address, so imported state always belongs to the same (tracked) relayer. - getUnexecutedBundleStartBlocks drops the requireExecution parameter; the non-execution path existed only for deposit counting. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
| // If we don't require execution verification, return the last relayed root bundle directly. | ||
| // This is used for deposit counting where the boundary is bundle validation/relay, not leaf execution. | ||
| if (!requireExecution) { | ||
| return true; | ||
| } |
There was a problem hiding this comment.
Why is this being removed? It seems irrelevant to the relayer cleanup.
There was a problem hiding this comment.
This branch existed only for deposit counting: deposits are bounded by bundle validation/relay rather than leaf execution, so getApproximateUpcomingDepositsForToken was the one caller passing requireExecution = false. #3602 removed the last consumer of getUpcomingDeposits (the running-balance reporter), so this PR drops upcoming-deposit tracking, and after that the only remaining caller (the refunds path) passes true — making this branch unreachable. The refund path is unaffected: it always required leaf execution and still does.
Happy to split the deposit-tracking removal (and this dead branch) into a separate PR if you'd rather keep this one strictly to the relayer filter.
| this.hubPoolClient, | ||
| this.chainIdList, | ||
| Array.from(allL1Tokens.values()).map((l1Token) => EvmAddress.from(l1Token)), | ||
| [this.relayer], |
There was a problem hiding this comment.
Does this work OK with non-EVM chain families? i.e. SVM and maybe TVM?
|
Thanks for the review — replied on the inline thread. Short version: the |
Resolves conflict with #3603 in the Monitor's BundleDataApproxClient construction: keep master's LP-token-only list and this branch's monitoredRelayers argument. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2 participants
Motivation
Prerequisite to #3598, split out per Paul in Slack.
#3602 (remove spoke pool running-balance reporter) deleted the last consumer that needed all-relayer refund sums from
BundleDataApproxClient. Every remaining consumer queries a relayer that is known at construction time:InventoryClientalways queries its own relayer, and the Monitor queries each of its configuredMONITORED_RELAYERS. Tracking every relayer on every spoke is now wasted work — and #3598 is about to make the per-fill bookkeeping heavier (repayment-chain/token resolution per fill), so shrinking the fill set first keeps that PR cheap.Changes
BundleDataApproxClienttakes the set of relayers to track and skips all other relayers' fills.InventoryClientpasses[this.relayer]; the Monitor passesmonitoredRelayers. Internal per-relayer keying is unchanged (the Monitor tracks several relayers).getUpcomingDepositslost its only consumer in chore(monitor): Remove spoke pool running-balance reporter #3602. The serializedBundleDataStateshape is unchanged —upcomingDepositsis exported empty — so Redis handover state remains compatible with older/newer relayer versions in both directions. The inventory cache key embeds the relayer address (InventoryClient#getInventoryCacheKey), so imported state always belongs to the same, tracked relayer.getUnexecutedBundleStartBlocksdrops therequireExecutionparameter; the non-execution path existed only for deposit counting.No README/AGENTS updates needed: internal client behavior only;
src/clients/README.mddescribes the refund-tracking role, which is unchanged.Testing
yarn hardhat test test/BundleDataApproxClient.ts test/InventoryClient.InventoryRebalance.ts test/InventoryClient.RefundChain.ts test/Monitor.ts test/Rebalancer.loadCumulativeModeBalances.ts test/JussiGraph.buildGraph.ts— 109 passingyarn build, eslint + prettier clean on touched files🤖 Generated with Claude Code