improve(InventoryClient): skip rebalances with no L1 -> L2 bridge route#3566
improve(InventoryClient): skip rebalances with no L1 -> L2 bridge route#3566droplet-rl wants to merge 2 commits into
Conversation
The rebalancer errors on every run with a generic "Token ... is not supported" assertion when the inventory config targets a token on a chain that has no L1 -> L2 bridge (e.g. Avalanche USDT, which is L2 -> L1 withdrawal-only via Binance). - InventoryClient now skips such rebalances and logs a warning naming the config mismatch instead of throwing at transfer time. - Split the sendTokenToTargetChain assertion so a missing L1 -> L2 bridge is distinguishable from a token missing from SUPPORTED_TOKENS. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 317a61d5a3
ℹ️ 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 (!this.adapterManager.canSendTokenCrossChain(chainId, l1Token)) { | ||
| unbridgeableRebalances.push(rebalance); | ||
| continue; |
There was a problem hiding this comment.
Preserve unbridgeable rebalances for same-asset routes
When runSameAssetRebalancer is used for the supported Avalanche USDT route, it gets its work items from inventoryClient.rebalanceInventoryIfNeeded(true) and then routes them through Binance (src/rebalancer/clients/SameAssetRebalancerClient.ts:49-54, src/rebalancer/buildSameAssetRebalanceRoutes.ts:7-10). This new guard filters out exactly those no-canonical-bridge imbalances before returnRebalancesOnly can hand them to the same-asset rebalancer, so Avalanche USDT deficits are only warned about and never initialized through the configured Binance route. The skip should apply only to direct InventoryClient sends, or otherwise preserve these rebalances for callers that execute alternate routes.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Good catch — confirmed: SameAssetRebalancerClient collects work items via rebalanceInventoryIfNeeded(true) and executes them through Binance, so the guard was filtering out exactly the rebalances that client exists to handle. Fixed in a096ac6: the skip now only applies when the InventoryClient executes the send itself (returnRebalancesOnly === false); collect-only callers still receive unbridgeable rebalances. Added a test covering the returnRebalancesOnly path and softened the warning to note the route may be handled by a rebalancer bot.
…lancesOnly callers The SameAssetRebalancerClient collects rebalances via rebalanceInventoryIfNeeded(true) and executes them through alternate routes (e.g. Avalanche USDT via Binance). The unbridgeable-rebalance skip was filtering those out before they could be returned, so such deficits would only ever be warned about and never rebalanced. Only apply the skip when the InventoryClient executes the send itself (returnRebalancesOnly === false), and soften the warning to note the route may be handled by a rebalancer bot. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
Addressed the Codex review finding in a096ac6. The P1 was valid: the new unbridgeable-rebalance guard also filtered rebalances out of the @codex review |
|
Codex Review: Didn't find any major issues. 🚀 Reviewed commit: ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
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". |
|
Codex re-review of a096ac6 came back clean. The PR now fixes the original "Token ... is not supported" crash while preserving the |
Motivation
Since #3564 enabled USDT on Avalanche in
SUPPORTED_TOKENS, the rebalancer errors on every run:Avalanche USDT is L2 -> L1 withdrawal-only (via Binance) — there is deliberately no entry in
CUSTOM_BRIDGE[AVALANCHE]and Avalanche has no canonical bridge. ButInventoryClient.rebalanceInventoryIfNeededselects rebalances purely from the inventory config, so whenever Avalanche USDT sits below its target allocation it attempts the L1 -> L2 send and trips the assert. The assert message is also misleading: it fires identically for "missing from SUPPORTED_TOKENS" and "no L1 -> L2 bridge configured", which makes it look like the SUPPORTED_TOKENS change didn't take effect.Slack context: https://riskmarkets.slack.com/archives/C073ELHSDQ8/p1783702598119989
Changes
InventoryClient.rebalanceInventoryIfNeededskips rebalances for (token, chain) pairs with no L1 -> L2 bridge and logs a warning pointing at the config mismatch, instead of throwing at transfer time. Same skip pattern chore: Enable withdrawing USDT via Binance from AVAX #3564 applied togetOutstandingCrossChainTransfers.AdapterManager.canSendTokenCrossChain/BaseChainAdapter.isSupportedL1Bridgehelpers (mirroring the existingisSupportedL2Bridge).sendTokenToTargetChainassertion so the two failure modes produce distinct messages.src/clients/README.mdon L2 -> L1-only tokens.Note this does not change which rebalances are possible — sends that previously threw are now skipped with a warn. If we later want L1 -> AVAX USDT rebalancing, that's a separate bridge-route addition (e.g. an L1-side Binance route).
Testing
InventoryClient.InventoryRebalance.ts— "Skips rebalances when the token has no L1 -> L2 bridge on the destination chain" (skip + warn, then executes normally once a route exists).yarn typecheck, eslint + prettier on changed files, and theInventoryClient.InventoryRebalance,InventoryClient.RefundChain,Monitorsuites all pass locally (64 passing).🤖 Generated with Claude Code