fc375ca72b
setup/register.ts had two bugs that prevented new channels from being
registered via `/manage-channels`:
1. createMessagingGroupAgent was called with the legacy field names
`trigger_rules` and `response_scope`. The SQL INSERT expects
`engage_mode` / `engage_pattern` / `sender_scope` / `ignored_message_policy`
(migration 010). Every register call failed with
`RangeError: Missing named parameter "engage_mode"` after the agent
and messaging group were partially created — leaving an orphaned pair.
Now mirrors scripts/init-first-agent.ts:wireIfMissing:
- Groups (is_group=1) default to engage_mode='mention' (bot only
responds when addressed).
- DMs (is_group=0) default to engage_mode='pattern' with '.' (respond
to every message).
- An explicit --trigger overrides the pattern regex.
2. The "normalize platform_id" block unconditionally prefixed
"<channel>:" even for native IDs like WhatsApp JIDs
("120363408974444974@g.us"), iMessage emails ("user@example.com"),
or Signal phones ("+15551234567") / Signal groups ("group:abc"). But
the router (src/router.ts:158) looks up messaging_groups by the raw
event.platformId from the adapter, which for these native adapters
never has a prefix. So the prefixed row was never matched — the
message was silently dropped with no "Message routed" log.
Extracted scripts/init-first-agent.ts:namespacedPlatformId into
src/platform-id.ts so both setup paths use the same heuristic (skip
the prefix for IDs containing '@', starting with '+', or starting
with 'group:'). Prevents future drift between the two paths.
Tested by: re-running `setup/index.ts --step register` for a WhatsApp
group JID, confirming the row is created with correct engage fields
and matching platform_id, then sending a test message and observing
"Message routed" with the right agent group.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
24 lines
1.2 KiB
TypeScript
24 lines
1.2 KiB
TypeScript
/**
|
|
* Determine whether a platform ID needs a channel-type prefix.
|
|
*
|
|
* Chat SDK adapters (Telegram, Discord, Slack, Teams, etc.) namespace their
|
|
* platform IDs with a channel prefix: "telegram:123456", "discord:guild:chan".
|
|
* The router stores channel_type and platform_id in separate columns, but
|
|
* Chat SDK adapters send the prefixed form as the platform_id — so any code
|
|
* that writes messaging_groups rows must produce the same shape the adapter
|
|
* will later emit as event.platformId, or router lookups miss and messages
|
|
* get silently dropped.
|
|
*
|
|
* Native adapters (Signal, WhatsApp, iMessage) use their own ID formats and
|
|
* send them as-is — no channel prefix. WhatsApp/iMessage emit JIDs/emails
|
|
* containing '@'. Signal emits raw phone numbers ('+15551234567') for DMs
|
|
* and 'group:<id>' for group chats. Prefixing any of these would cause a
|
|
* mismatch with what the adapter later emits.
|
|
*/
|
|
export function namespacedPlatformId(channel: string, raw: string): string {
|
|
if (raw.startsWith(`${channel}:`)) return raw;
|
|
if (raw.includes('@')) return raw;
|
|
if (raw.startsWith('+') || raw.startsWith('group:')) return raw;
|
|
return `${channel}:${raw}`;
|
|
}
|