fix: use handleMessage instead of sendMessage for elizaOS unified API#41
fix: use handleMessage instead of sendMessage for elizaOS unified API#41
Conversation
WalkthroughRenamed the unified messaging API method from Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches🧪 Generate unit tests (beta)
📜 Recent review detailsConfiguration used: Organization UI Review profile: CHILL Plan: Pro Cache: Disabled due to data retention organization setting Knowledge base: Disabled due to data retention organization setting 📒 Files selected for processing (1)
✅ Files skipped from review due to trivial changes (1)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Fix all issues with AI agents
In @src/utils.ts:
- Around line 49-54: The current hasUnifiedMessagingAPI runtime check looks for
runtime.elizaOS.handleMessage, which is a non-standard pattern for @elizaos/core
v1.7.0; change the detection to prefer the standard messageService API by
checking for runtime.messageService && typeof
runtime.messageService.handleMessage === "function" (and optionally keep a
secondary check for runtime.elizaOS && typeof runtime.elizaOS.handleMessage ===
"function" for legacy compatibility), updating the hasUnifiedMessagingAPI
function accordingly and ensuring code paths that rely on unified messaging (see
messages.ts fallback referencing messageService.handleMessage) will use the
messageService detection first.
🧹 Nitpick comments (1)
src/utils.ts (1)
25-31: Interface and runtime check are consistent with the API rename.The
UnifiedMessagingAPIinterface correctly exposeshandleMessagewith the expected signature, and thehasUnifiedMessagingAPIfunction at lines 49-54 properly checks forelizaOS.handleMessage. The changes are internally consistent.Consider strengthening the types in a follow-up:
message: anyandonResponse?: anylose type safety. Using the actualMemoryandHandlerCallbacktypes from@elizaos/corewould improve maintainability.
📜 Review details
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Cache: Disabled due to data retention organization setting
Knowledge base: Disabled due to data retention organization setting
📒 Files selected for processing (2)
src/messages.tssrc/utils.ts
🧰 Additional context used
🧬 Code graph analysis (1)
src/utils.ts (1)
src/types.ts (2)
DiscordActionRow(535-538)DiscordComponentOptions(520-533)
🔇 Additional comments (2)
src/messages.ts (2)
447-477: API method rename applied correctly with consistent fallback chain.The call to
unifiedAPI.handleMessageat line 455 correctly uses the renamed method with the same argument structure. The fallback logic tomessageService.handleMessage(line 464) and event-based handling (lines 471-476) remains intact, ensuring backward compatibility with older core versions.
455-457: No action required. Verification confirms no stalesendMessagereferences remain in the codebase that could cause runtime errors. The refactoring fromsendMessagetohandleMessageis complete and safe.
| export function hasUnifiedMessagingAPI(runtime: IAgentRuntime): boolean { | ||
| const runtimeAny = runtime as any; | ||
| return !!(runtimeAny.elizaOS && typeof runtimeAny.elizaOS.sendMessage === 'function'); | ||
| return !!( | ||
| runtimeAny.elizaOS && typeof runtimeAny.elizaOS.handleMessage === "function" | ||
| ); | ||
| } |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# Find package.json to check the actual version
find . -name "package.json" -type f | head -5 | xargs catRepository: elizaos-plugins/plugin-discord
Length of output: 4121
🏁 Script executed:
# Search for references to elizaOS and handleMessage in the codebase
rg "elizaOS|handleMessage" -t ts -t js --max-count 20Repository: elizaos-plugins/plugin-discord
Length of output: 3321
🏁 Script executed:
# Look for IAgentRuntime definition to understand the interface
rg "interface IAgentRuntime|type IAgentRuntime" -A 10 -t ts -t jsRepository: elizaos-plugins/plugin-discord
Length of output: 12407
🏁 Script executed:
# Search for references to sendMessage to understand the deprecation
rg "sendMessage" -t ts -t js --max-count 15Repository: elizaos-plugins/plugin-discord
Length of output: 604
🏁 Script executed:
# Search for UnifiedMessagingAPI type definition
rg "UnifiedMessagingAPI|interface.*MessageAPI" -B 3 -A 10 -t tsRepository: elizaos-plugins/plugin-discord
Length of output: 3623
🏁 Script executed:
# Look at the complete getUnifiedMessagingAPI and hasUnifiedMessagingAPI functions
sed -n '40,80p' src/utils.tsRepository: elizaos-plugins/plugin-discord
Length of output: 1458
🏁 Script executed:
# Search for any comments or documentation about the elizaOS API
rg "elizaOS|unified.*messaging" -B 2 -A 2 -t ts | head -60Repository: elizaos-plugins/plugin-discord
Length of output: 2253
🌐 Web query:
elizaOS core 1.7.0 unified messaging handleMessage API
💡 Result:
Summary (elizaOS core — handleMessage / unified messaging, v1.7.x)
- Where: exported from @elizaos/core (Agent runtime API / Types). [1][2]
- Main signatures:
- handleMessage(agentId: UUID | IAgentRuntime, message: Message, options?: HandleMessageOptions): Promise. [1]
- handleMessages(messages: Array<{ agentId: UUID; message: Message }>): Promise<HandleMessageResult[]> (batch API). [1]
- Key types (most important fields):
- HandleMessageOptions: onResponse, onStreamChunk, onError, onComplete, skipEvaluators, skipActions. (callbacks usable for streaming/async processing). [1]
- HandleMessageResult: { messageId: UUID; userMessage: Memory; processing?: { text: string; actions?: ActionResult[]; evaluations?: unknown[] }; error?: Error }. [1]
- Behavior:
- Routes inbound messages through the runtime’s message-processing core (bootstrap plugin) and the unified message bus so the same handler works for WebSocket, Discord/Telegram adapters, HTTP, etc. Output may be streamed via onStreamChunk/onResponse callbacks or returned fully in processing.text. [2][3]
- Notes:
- Use handleMessages for parallel/batched deliveries (returns array of HandleMessageResult). [1]
- Options allow skipping evaluator/action phases if you only want raw response text or lower-latency handling. [1]
Sources
- Types & API reference (handleMessage, options, result shape). [1]
- Messaging / runtime and bootstrap (unified message bus, message flow through bootstrap/core). [2][3]
🌐 Web query:
@elizaos/core 1.7.0 release notes handleMessage runtime
💡 Result:
Do you want a brief summary of what's changed in @elizaos/core v1.7.0 (specifically handleMessage/runtime), or the direct release notes / links (GitHub release, changelog, or commit diff)? I can search GitHub, npm, and the docs and return citations.
🌐 Web query:
elizaOS IAgentRuntime elizaOS.handleMessage documentation
💡 Result:
Short answer — documentation and signatures:
-
The elizaOS docs describe IAgentRuntime and the runtime HandleMessage API in the Types Reference. The handleMessage signature is:
handleMessage(
agentId: UUID | IAgentRuntime,
message: Message,
options?: HandleMessageOptions
): Promise
— with HandleMessageOptions (onResponse, onStreamChunk, onError, onComplete, skipEvaluators, skipActions) and HandleMessageResult (messageId, userMessage, processing, error). [1] -
For broader context on IAgentRuntime (properties and runtime methods like composeState, processActions, evaluate, register* and model/service management) see the Core / AgentRuntime pages. [2][3]
Sources:
- Types Reference — HandleMessage, HandleMessageOptions, HandleMessageResult. [1]
- Core / AgentRuntime overview (IAgentRuntime methods & properties). [2]
- Plugins / Reference pages for related interfaces and examples. [3]
The check for runtime.elizaOS.handleMessage uses a non-standard API pattern for v1.7.0.
While @elizaos/core 1.7.0 does export a handleMessage API, it is not exposed as runtime.elizaOS.handleMessage. The standard unified messaging pattern in 1.7.0 routes through messageService.handleMessage (as evidenced by the fallback in messages.ts). The defensive check here appears to handle a legacy or optional API pattern that may not exist in the target version. Consider confirming whether the elizaOS wrapper is guaranteed to exist, or rely primarily on the messageService fallback.
🤖 Prompt for AI Agents
In @src/utils.ts around lines 49 - 54, The current hasUnifiedMessagingAPI
runtime check looks for runtime.elizaOS.handleMessage, which is a non-standard
pattern for @elizaos/core v1.7.0; change the detection to prefer the standard
messageService API by checking for runtime.messageService && typeof
runtime.messageService.handleMessage === "function" (and optionally keep a
secondary check for runtime.elizaOS && typeof runtime.elizaOS.handleMessage ===
"function" for legacy compatibility), updating the hasUnifiedMessagingAPI
function accordingly and ensuring code paths that rely on unified messaging (see
messages.ts fallback referencing messageService.handleMessage) will use the
messageService detection first.
1 participant
Greptile Overview
Greptile Summary
This PR updates the Discord plugin to use the new
handleMessagemethod instead of the deprecatedsendMessagemethod in the elizaOS unified messaging API. The changes are clean and complete:UnifiedMessagingAPIinterface definition to usehandleMessagehasUnifiedMessagingAPIto detect the new methodmessages.tsto invokehandleMessageThe PR also includes formatting changes (single to double quotes) that appear to be from an auto-formatter. All changes are backward compatible since they only affect the new unified API path, with fallbacks to
messageServiceand event-based handling still intact.Confidence Score: 5/5
Important Files Changed
File Analysis
sendMessagetohandleMessageat line 455, aligning with the new interface definitionUnifiedMessagingAPIinterface andhasUnifiedMessagingAPIfunction to usehandleMessageinstead of deprecatedsendMessage, includes formatting changes (quote style)Sequence Diagram
sequenceDiagram participant Discord as Discord Message participant MM as MessageManager participant Utils as getUnifiedMessagingAPI() participant Runtime as IAgentRuntime participant UnifiedAPI as elizaOS.handleMessage participant MsgService as messageService.handleMessage participant Callback as HandlerCallback Discord->>MM: handleMessage(message) MM->>MM: processMessage() MM->>MM: buildMemoryFromMessage() MM->>Utils: getUnifiedMessagingAPI(runtime) Utils->>Runtime: Check elizaOS.handleMessage exists alt Unified API Available (NEW) Runtime-->>Utils: elizaOS.handleMessage found Utils-->>MM: Return UnifiedMessagingAPI MM->>UnifiedAPI: handleMessage(agentId, message, {onResponse: callback}) UnifiedAPI->>Callback: Execute callback with content Callback->>Discord: Send response to channel else MessageService Available Runtime-->>Utils: messageService found Utils-->>MM: Return null, check messageService MM->>MsgService: handleMessage(runtime, message, callback) MsgService->>Callback: Execute callback with content Callback->>Discord: Send response to channel else Legacy Event-based Runtime-->>Utils: Neither available Utils-->>MM: Return null MM->>Runtime: emitEvent(MESSAGE_RECEIVED) Runtime->>Callback: Execute callback with content Callback->>Discord: Send response to channel endSummary by CodeRabbit
✏️ Tip: You can customize this high-level summary in your review settings.