You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This PR introduces normalizeTelegramDeliveryGroupChatId and applies it in normalizeTelegramChatId and normalizeTelegramLookupTarget, which correctly handles the negative-ID case (e.g., group:-100123) end-to-end. However, the fix is incomplete because parseTelegramTarget — the entry point for all send helpers and resolveTelegramTargetChatType — is not updated.
Functional issues:
Positive-ID send path is broken (group:123456789): The colonMatch regex in parseTelegramTarget splits "group:123456789" as chatId = "group" and messageThreadId = 123456789. The subsequent resolveChatId("group", …) call then matches "group" as a 5-character username and makes a spurious getChat("@group") API call instead of delivering to the intended chat.
resolveTelegramTargetChatType returns "unknown" for group: prefixed targets: Because parseTelegramTarget does not apply normalization, resolveTelegramTargetChatType("group:-1001234567890") resolves to "unknown" instead of "group". In exec-approvals.ts, approval buttons are silently suppressed for group-prefixed targets when the approval target is configured as "channel", since the condition only enables buttons for target === "channel" when chatType === "group".
Confidence Score: 1/5
Not safe to merge — the PR is incomplete and leaves two functional regressions that will cause broken sends and suppressed approval buttons for group-prefixed targets.
The normalization helper is correct and negative-ID cases work end-to-end, but parseTelegramTarget is not updated. This leaves two real bugs: (1) positive-ID group:... inputs are misparsed and trigger spurious API calls, and (2) chat-type resolution returns "unknown" instead of "group", causing approval buttons to be silently suppressed for group targets when configured as "channel". These are functional regressions against the invariants the PR's own tests establish.
src/telegram/targets.ts — specifically parseTelegramTarget (line 97) and resolveTelegramTargetChatType (line 124) need to apply normalizeTelegramDeliveryGroupChatId before the colon-match logic runs.
parseTelegramTarget does not apply normalizeTelegramDeliveryGroupChatId, leaving the positive-ID send path broken.
For input "group:123456789", the colonMatch regex /^(.+):(\d+)$/ on line 109 will eagerly match and split the string as chatId = "group" and messageThreadId = 123456789. The downstream resolveChatId("group", …) call in send.ts then runs normalizeTelegramLookupTarget("group"), which matches the TELEGRAM_USERNAME_REGEX (5 alphanumeric characters) and returns "@group", causing an unexpected getChat("@group") API call instead of delivering to the intended chat ID.
Note: negative-ID inputs like "group:-100123" are unaffected because the colonMatch regex requires digits after the colon (not minus), so it fails to match and the full string is passed through.
Fix: Apply normalizeTelegramDeliveryGroupChatId to normalized early in parseTelegramTarget, before the colon-match logic runs — analogous to how it is now applied in normalizeTelegramChatId and normalizeTelegramLookupTarget.
resolveTelegramTargetChatType returns wrong type for group: prefixed targets.
Since parseTelegramTarget does not apply normalizeTelegramDeliveryGroupChatId, inputs like "group:-1001234567890" are not normalized and remain unparseable, causing parseTelegramTarget to return chatType: "unknown" instead of the correct "group" type.
This has a concrete downstream effect in exec-approvals.ts. When a user's approval target is configured as "channel", the approval-button logic only enables buttons if chatType === "group":
if(chatType==="group"){returntarget==="channel"||target==="both";}returntarget==="both";// ← exec-approval buttons silently suppressed when chatType is "unknown"
With chatType resolving to "unknown" for group:... targets, the condition falls through and approval buttons are silently suppressed for users who configure the approval target as "channel".
Fix: Updating parseTelegramTarget to apply normalizeTelegramDeliveryGroupChatId (as noted in the previous comment) will also resolve this issue.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
openclaw-barnacle
bot
added
channel: telegram
Summary
group:<numeric_chat_id>targets in Telegram delivery helpersTesting