Problem
useSwapRates.ts:58-62 filters every API response through new Set(Object.values(SwapperName)) — the widget's own enum, which currently lists four swappers while the API serves nine.
Rates from Bebop, ButterSwap, Chainflip, Portals and 0x arrive over the wire and are dropped on the floor with no signal. The user sees "No routes found" (InputStep.tsx:131) in cases where the API returned perfectly good routes, and there is nothing distinguishing "no route exists" from "filtered out client-side".
This also means we pay for rate requests across all enabled API swappers and discard more than half the response.
Work
- Distinguish the two states — at minimum log when rates are dropped by the enum filter, so this is diagnosable from a partner bug report
- Consider passing
allowedSwapperNames through to the API request instead of filtering the response, so we don't ask for rates we intend to discard. The API already accepts a swapper restriction on quote; check whether rates can take one too
- Once the staged swappers are enabled, the filter narrows to nothing and this becomes cheap — but the silent-drop behaviour should not be what protects us in the meantime
Problem
useSwapRates.ts:58-62filters every API response throughnew Set(Object.values(SwapperName))— the widget's own enum, which currently lists four swappers while the API serves nine.Rates from Bebop, ButterSwap, Chainflip, Portals and 0x arrive over the wire and are dropped on the floor with no signal. The user sees "No routes found" (
InputStep.tsx:131) in cases where the API returned perfectly good routes, and there is nothing distinguishing "no route exists" from "filtered out client-side".This also means we pay for rate requests across all enabled API swappers and discard more than half the response.
Work
allowedSwapperNamesthrough to the API request instead of filtering the response, so we don't ask for rates we intend to discard. The API already accepts a swapper restriction on quote; check whether rates can take one too