fix: include messageId in notifier message_complete events#23048
Conversation
Watch handler (commentary/summary) and call question notifier message_complete events were emitted without messageId. When these fired mid-stream for the same conversation, the client's handleMessageComplete would clear currentAssistantMessageId without setting daemonMessageId, causing the LLM Context Inspector to show 0 calls until the app was restarted and history reconstruction assigned the correct ID. Thread the already-available msg.id from addMessage() into the message_complete events for all three notifier paths that persist messages. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
There was a problem hiding this comment.
🚩 Incomplete messageId propagation across broader codebase
This PR adds messageId to message_complete events only within conversation-notifiers.ts. There are many other message_complete emissions in conversation-process.ts:415,501,763,871,933 and handlers/recording.ts:493,546,574,607,674,714,839,971,1005 that also omit messageId. Some of those do persist messages (e.g. slash command handlers in conversation-process.ts that call addMessage). If the intent is for clients to reliably receive messageId on all persisted-message completions, those sites would need the same treatment. However, since messageId is optional on MessageComplete (message-types/messages.ts:197) and clients handle its absence gracefully, this is not a bug — just a potential follow-up for consistency.
Was this helpful? React with 👍 or 👎 to provide feedback.
1 participant
Summary
messageIdin theirmessage_completeSSE eventsmsg.idfromaddMessage()was already available in all three paths — just not threaded through to the eventOriginal prompt
these 2 PRs
🤖 Generated with Claude Code