← Back to PRs

#15727: fix(routing): resolve channel default account instead of hardcoded 'default'

by FuseWeb open 2026-02-13 19:47 View on GitHub →
size: S
## Summary Fixes #9198 — binding routing fails for multi-account channels where the default account id is not literally `"default"`. ## Root Cause `matchesAccountId()` in `src/routing/resolve-route.ts` compared the inbound account against the hardcoded `DEFAULT_ACCOUNT_ID` (`"default"`) when a binding omitted `accountId`. This meant bindings like: ```yaml bindings: - agentId: bizPeer match: channel: whatsapp peer: { kind: direct, id: "+1000" } ``` …would never match on a channel whose sole (and thus default) account is named `"biz"`. ## Fix - Use `resolveChannelDefaultAccountId` from `src/channels/plugins/helpers.ts` to determine the channel's actual default account id. - Normalize both sides of the comparison via `normalizeAccountId` from `session-key.ts`. - Added regression test for the non-literal default account scenario. ## Testing - All 30 existing + 1 new test pass (`pnpm test src/routing/resolve-route.test.ts`) - [x] AI-assisted (Claude, fully tested) - [x] I understand what this code does <!-- greptile_comment --> <h2>Greptile Overview</h2> <h3>Greptile Summary</h3> This PR fixes account matching for bindings that omit `accountId` by resolving the channel’s actual default account id (instead of comparing against the hardcoded `"default"`), and adds a regression test for channels whose default account id is non-literal. The change is implemented in `src/routing/resolve-route.ts` by introducing a helper that looks up the channel plugin and asks it (via `resolveChannelDefaultAccountId`) for the default account id, then uses that value when deciding whether a binding with no `accountId` matches. The test suite is extended in `src/routing/resolve-route.test.ts` to cover a single-account channel named `"biz"`. <h3>Confidence Score: 2/5</h3> - This PR has a real risk of breaking routing in config-only / early-init contexts due to relying on the runtime plugin registry during route resolution. - The functional intent looks correct and a regression test was added, but `resolveAgentRoute()` now imports/calls `getChannelPlugin()` from the runtime plugin registry module, which can throw if the registry isn’t initialized and also pulls heavy runtime dependencies into a shared routing path. That’s a behavior change that can surface at runtime outside the test case. - src/routing/resolve-route.ts <sub>Last reviewed commit: ee90398</sub> <!-- greptile_other_comments_section --> <sub>(3/5) Reply to the agent's comments like "Can you suggest a fix for this @greptileai?" or ask follow-up questions!</sub> <!-- /greptile_comment -->

Most Similar PRs