Summary
In extras/scion-telegram/internal/telegram/broker_v2.go, both
handleGroupMessage and handleCallbackQuery resolve a registered
Telegram user's Hub identity mapping to get their email
(mapping.ScionEmail) for the outbound StructuredMessage.Sender display
string, but never resolve their Hub user ID for SenderID — it stays
the raw Telegram numeric ID even when a mapping (with ScionUserID
already populated by /register) is found:
mapping, err := b.store.GetUserMapping(ctx, senderID)
if err == nil && mapping != nil {
if mapping.ScionEmail != "" {
sender = "user:" + mapping.ScionEmail
}
// mapping.ScionUserID is never used here
}
Impact
The Hub's outbound-message reply-affinity table
(webchat_conversation_context, in pkg/hub) is keyed by Hub user UUID.
When an inbound Telegram message arrives, the Hub records "last channel =
telegram" under whatever SenderID this plugin sent — the raw Telegram
numeric ID, not the Hub UUID. When an agent's reply is later resolved to a
recipient by Hub user UUID (e.g. via the agent-creator fallback in #1229),
the reply-affinity lookup uses that UUID as the key and finds nothing
matching what was recorded — so the reply falls back to whatever channel
that Hub user last used elsewhere (e.g. the web dashboard) instead of
routing back to Telegram, with no error anywhere in the chain.
Repro
- Register a Telegram user (
/register) against a Hub user, confirm
user_mappings.scion_user_id is populated in the plugin's local DB.
- Send a message from Telegram, have an agent reply.
- Hub log shows the reply's outbound dispatch with
"channel":"web"
instead of "channel":"telegram", even though the inbound message came
in on "channel":"telegram".
Fix
PR incoming: resolve mapping.ScionUserID into a separate hubSenderID
used for the outbound SenderID, keeping the raw Telegram ID (senderID)
for the fields that still need it (ConversationContext.TelegramUserID).
Summary
In
extras/scion-telegram/internal/telegram/broker_v2.go, bothhandleGroupMessageandhandleCallbackQueryresolve a registeredTelegram user's Hub identity mapping to get their email
(
mapping.ScionEmail) for the outboundStructuredMessage.Senderdisplaystring, but never resolve their Hub user ID for
SenderID— it staysthe raw Telegram numeric ID even when a mapping (with
ScionUserIDalready populated by
/register) is found:Impact
The Hub's outbound-message reply-affinity table
(
webchat_conversation_context, inpkg/hub) is keyed by Hub user UUID.When an inbound Telegram message arrives, the Hub records "last channel =
telegram" under whatever
SenderIDthis plugin sent — the raw Telegramnumeric ID, not the Hub UUID. When an agent's reply is later resolved to a
recipient by Hub user UUID (e.g. via the agent-creator fallback in #1229),
the reply-affinity lookup uses that UUID as the key and finds nothing
matching what was recorded — so the reply falls back to whatever channel
that Hub user last used elsewhere (e.g. the web dashboard) instead of
routing back to Telegram, with no error anywhere in the chain.
Repro
/register) against a Hub user, confirmuser_mappings.scion_user_idis populated in the plugin's local DB."channel":"web"instead of
"channel":"telegram", even though the inbound message camein on
"channel":"telegram".Fix
PR incoming: resolve
mapping.ScionUserIDinto a separatehubSenderIDused for the outbound
SenderID, keeping the raw Telegram ID (senderID)for the fields that still need it (
ConversationContext.TelegramUserID).