Bugfix: Why were manage_group and send_message LLM tools always retu...

Documentation for Sessions

🐛 Bugfix: Why were manage_group and send_message LLM tools always retu...

Date: 2026-03-21
Time: 17:13:18 UTC
Session: gspace1-250.2
Agent: backend
Confidence: 98%
Status: ✅ Documented

📋 Decision Context

Question:

Why were manage_group and send_message LLM tools always returning errors despite services being fully implemented?

Task: S250: Unified channel completion — wire dormant messaging tools

🎯 Decision Made

Chosen:

Injected GroupOrchestrationService and ChannelGatewayService into ToolRegistryService via @Optional() constructor parameters, replacing hardcoded undefined values at lines 503-504

Options Considered:

  1. Wire services directly (chosen — follows existing whistleOrchestrator pattern)
  2. Create a ToolContextBuilder service to centralize context assembly
  3. Remove the tools entirely since they were unused

💭 Reasoning

Root cause: tool-registry.service.ts lines 503-504 hardcoded groupOrchestration: undefined and channelGateway: undefined in the ToolPluginContext. The services existed, were fully implemented, registered in ConnectivityModule, and ConnectivityModule was imported by EngineModule — but nobody wired them into the tool context. The ToolPluginContext interface (tool-plugin.types.ts:84-96) already defined the shape. The pattern for wiring was established by whistleOrchestrator (lines 505-510). This was a 2-line fix with maximum leverage — it unlocked the entire group messaging and direct messaging tool system that had been dormant since S174. The bug survived because: (1) no test verified tool context completeness, (2) the tools gracefully returned error strings rather than crashing, masking the issue, (3) the undefined was intentional placeholder code that was never revisited.

📁 Files Involved

🔗 Related

Auto-generated by MCP Smart Consolidation