Telegram: fix webhook multi-account routing (respect bindings.accountId)#821
Conversation
There was a problem hiding this comment.
Pull request overview
This PR fixes a routing bug where Telegram webhook messages were always routed with accountId=default, preventing account-specific bindings from matching correctly. The fix ensures that the accountId and config are passed through the webhook initialization flow to createTelegramBot(), enabling proper multi-account routing.
Changes:
- Added
accountIdandconfigparameters to webhook initialization flow - Updated webhook and bot tests to verify correct accountId routing behavior
- Maintained backward compatibility by making new parameters optional
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| src/telegram/webhook.ts | Added accountId and config optional parameters to startTelegramWebhook() and passed them to createTelegramBot() |
| src/telegram/monitor.ts | Updated webhook initialization to pass accountId and config from the resolved account |
| src/telegram/webhook.test.ts | Added test verification that accountId is forwarded to createTelegramBot() |
| src/telegram/bot.test.ts | Added comprehensive test verifying that DMs are correctly routed by accountId binding to the appropriate agent session |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| expect(createTelegramBotSpy).toHaveBeenCalledWith( | ||
| expect.objectContaining({ accountId: "opie" }), | ||
| ); |
There was a problem hiding this comment.
The test verifies that accountId is passed to createTelegramBot, but doesn't verify that config is also passed. Consider also checking for the config parameter in the assertion to ensure both new parameters are properly forwarded.
The Telegram webhook and monitor now accept and pass through accountId and config parameters, enabling routing and configuration per Telegram account. Tests have been updated to verify correct bot instantiation and DM routing based on accountId bindings.
Refactors tests to use a shared config object and adds stricter assertions to verify that the config is passed correctly to createTelegramBot. Ensures the bindings property is checked in the test expectations.
641a55a to
bab7eea
Compare
|
Landed via temp rebase onto main. Thanks @gumadeiras! |
…-webhook Telegram: fix webhook multi-account routing (respect bindings.accountId)
…me-instance-cleanup WIP: Simplify plugin runtime and cleanup lifecycle
Fixes #803
This PR fixes a routing bug where Telegram inbound messages received via webhook mode were always routed as
accountId=default, causing bindings like{ provider: "telegram", accountId: "opie" }to never match and messages to fall back to the default agent (main). The webhook server now passes the configuredaccountId(and loaded config) intocreateTelegramBot(), soresolveAgentRoute()evaluates bindings correctly and sessions no longer leak across agents.What changed
startTelegramWebhook()now acceptsaccountId+configand forwards both intocreateTelegramBot().accountId+configintostartTelegramWebhook()when webhook mode is enabled.accountIdintocreateTelegramBot().bindings.match.accountIdroutes a DM to the bound agent session.Reproduction
Config:
Before:
opiebot routes toagent:main:...(binding doesn’t match because webhook bot runs asaccountId=default).After:
opiebot routes toagent:opie:mainand payload carriesAccountId: "opie".Validation
Tested locally with three bots and works as intended.
Sample config:
Notes / follow-ups
resolveAgentRoute()without anaccountId, so account-scoped bindings can’t work there until a stable account identifier is defined for Teams.