Users without a visible phone number (like some Signal users)
were being silently dropped. Now falls back to UUID for sender ID.
- Add sourceUuid to SignalEnvelope type
- Use sourceUuid when sourceNumber is not available
- Only check against bot account when sourceNumber exists (avoid UUID comparison issues)
When cron jobs specify a Telegram topic in the 'to' field like
'-1003420657307:topic:60', the delivery code now correctly parses
this into separate chatId and messageThreadId values.
Previously, the entire string was passed as chatId, causing messages
to fail delivery to forum topics.
Heartbeat Telegram delivery was failing when the bot token was
configured only via telegram.botToken in config (without TELEGRAM_BOT_TOKEN
environment variable).
Root cause: deliverOutboundPayloads was called without accountId parameter,
so sendMessageTelegram couldn't determine which account to use and couldn't
find the token from config.
Fix: Resolve default Telegram accountId when provider is "telegram" and pass
it to deliverOutboundPayloads. This follows the same pattern used elsewhere in
the codebase (e.g., cron uses resolveTelegramToken).
Changes:
- Added import for resolveDefaultTelegramAccountId
- Added accountId resolution for telegram provider
- Updated deliverOutboundPayloads call to include accountId
Fixes#318
Co-Authored-By: Claude <noreply@anthropic.com>
Fixes parameter mismatch between AI tool schema and internal validation.
The TypeBox schema now uses `jobId` for update/remove/run/runs actions,
matching what users expect based on the returned job objects.
Changes:
- Changed parameter from `id` to `jobId` in TypeBox schema for update/remove/run/runs
- Updated execute function to read `jobId` parameter
- Updated tests to use `jobId` in input parameters
The gateway protocol still uses `id` internally - the tool now maps
`jobId` from the AI to `id` for the gateway call.
Fixes#185
Co-Authored-By: Claude <noreply@anthropic.com>
