fix: deliver proactive messages via senderId fallback#79
Closed
paulscan wants to merge 1 commit intoTinyAGI:mainfrom
Closed
fix: deliver proactive messages via senderId fallback#79paulscan wants to merge 1 commit intoTinyAGI:mainfrom
paulscan wants to merge 1 commit intoTinyAGI:mainfrom
Conversation
Channel clients were deleting outgoing messages that had no matching pendingMessages entry. Proactive messages (from send-user-message skill, heartbeat, scheduled tasks) never have a pending entry since they aren't triggered by an incoming user message. All three clients now fall back to the senderId field in the response JSON to resolve the target chat/user. Proactive messages are sent without reply_to_message_id since there's no original message. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
paulscan
force-pushed
the
paul/fix-proactive-messages
branch
from
7aa4186 to
0687ebd
Compare
jlia0
added a commit
that referenced
this pull request
Feb 15, 2026
Channel clients had duplicated code paths for pending (request-response) and proactive (senderId-based) message delivery. Merge into a single flow that resolves the target from pendingMessages first, then falls back to senderId. This removes ~40 lines of duplicated logic per client and fixes WhatsApp missing await on reply. Also adds --files usage example to send-user-message SKILL.md. Supersedes #79 Co-Authored-By: Paul Scandariato <ps@scannedinc.com> Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
4 tasks
Collaborator
|
implemented in #95 |
jlia0
added a commit
that referenced
this pull request
Feb 15, 2026
Channel clients had duplicated code paths for pending (request-response) and proactive (senderId-based) message delivery. Merge into a single flow that resolves the target from pendingMessages first, then falls back to senderId. This removes ~40 lines of duplicated logic per client and fixes WhatsApp missing await on reply. Also adds --files usage example to send-user-message SKILL.md. Supersedes #79 Co-authored-by: Paul Scandariato <ps@scannedinc.com> Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
Summary
senderIdfieldin outgoing queue messages when there's no matching
pendingMessagesentryProblem
The
send-user-messageskill (added in #59) writes correctly formatted messages toqueue/outgoing/, but all three channel clients delete them without delivery. Theoutgoing queue handler requires a
pendingMessagesentry (created when an incomingmessage arrives), and proactive messages by definition have none.
Fix
Each channel client's
checkOutgoingQueuefunction now checks forsenderIdin theresponse JSON when
pendingMessageshas no match. ThesenderIdis used to resolvethe target chat directly (Telegram chat ID, Discord user ID → DM, WhatsApp chat ID).
Test plan
send_message.ts send --channel telegramdeliverssuccessfully instead of producing a WARN log