Telegram Messaging Gap-Closure#6247
Conversation
…6210) Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Claude <noreply@anthropic.com>
…d rejection visibility (#6212) Co-authored-by: Claude <noreply@anthropic.com>
#6222) Co-authored-by: Claude <noreply@anthropic.com>
…bilities (#6238) Co-authored-by: Claude <noreply@anthropic.com>
…6241) Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Claude <noreply@anthropic.com>
…nection error handling (#6244) Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Claude <noreply@anthropic.com>
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: e466e7b34e
ℹ️ 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".
| GATEWAY_RUNTIME_PROXY_ENABLED: "true", | ||
| GATEWAY_RUNTIME_PROXY_REQUIRE_AUTH: "false", | ||
| RUNTIME_HTTP_PORT: process.env.RUNTIME_HTTP_PORT || "7821", | ||
| GATEWAY_UNMAPPED_POLICY: process.env.GATEWAY_UNMAPPED_POLICY || "default", |
There was a problem hiding this comment.
Preserve reject routing unless deployment is single-assistant
startGateway() now unconditionally sets GATEWAY_UNMAPPED_POLICY to default and picks loadLatestAssistant() as GATEWAY_DEFAULT_ASSISTANT_ID, so in any local workspace with multiple assistants or partial routing maps, unmapped Telegram chats are silently delivered to whichever assistant was most recently hatched instead of being rejected. That can route messages to the wrong assistant and contaminate conversations; this default should only be applied when the deployment is provably single-assistant.
Useful? React with 👍 / 👎.
| * registry detect that Telegram credentials exist. | ||
| */ | ||
| isConnected(): boolean { | ||
| return getBotToken() !== undefined; |
There was a problem hiding this comment.
Treat Telegram as connected only when full delivery creds exist
The Telegram provider reports connected when only credential:telegram:bot_token exists, but outbound delivery goes through /deliver/telegram, which is gated by isTelegramConfigured() in gateway/src/index.ts and requires both bot token and webhook secret. In a partial-credential state (for example after secret deletion/rotation drift), tools will auto-select Telegram as connected and every send fails at runtime; isConnected() should validate the webhook secret too so connectivity status matches actual deliverability.
Useful? React with 👍 / 👎.
… Telegram adapter (#6257) Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Claude <noreply@anthropic.com>
Summary
Deliver production-ready Telegram messaging by closing critical gaps: fix attachment delivery, add proactive outbound send via bot identity, make routing reliable for single-assistant deployments, automate webhook lifecycle reconciliation, harden internal delivery auth, and align all docs with actual capabilities.
Changes
assistantIdfor Telegram attachment downloads — attachments now use/v1/attachments/:attachmentIdendpointGATEWAY_UNMAPPED_POLICY=defaultandGATEWAY_DEFAULT_ASSISTANT_IDin local gateway startup; add operator-visible Telegram notice on routing rejectiongetWebhookInfo/setWebhook/deliver/telegramunconditionally (fail-closed by default), with explicit dev bypass flagMilestone PRs (merged into feature branch)
Feedback PRs (merged into feature branch)
Project issue
Closes #6200
Test plan
/deliver/telegramrejects unauthenticated public requests🤖 Generated with Claude Code