fix(mcp-over-acp): elicitation passthrough correlation registry - #116
Closed
Million-mo wants to merge 2 commits into
Closed
fix(mcp-over-acp): elicitation passthrough correlation registry#116Million-mo wants to merge 2 commits into
Million-mo wants to merge 2 commits into
Conversation
* feat(acp): batch SessionUpdate delivery during replay Refactor ACPNotifications.replay() from sequential per-update session/update notifications to collect-then-batch-send pattern: - Add _collect_request_updates/_collect_response_updates as pure conversion methods returning list[SessionUpdate] (no I/O) - Add send_batch_update() that uses ext_notification _batch_session_updates when client supports it, falls back to sequential session/update otherwise - Add notification_batch_size (default 20) and notification_flush_interval (default 0.0) constructor params to ACPNotifications - Add set_batch_support() for capability-based opt-in - Wire batch support detection into ACPSession.__post_init__ via client_capabilities.field_meta - Keep _replay_request/_replay_response as thin wrappers for backward compatibility - Add 6 new tests covering batch mode, fallback, ordering, custom size, pure collector, and empty messages - Add benchmark script comparing batch vs sequential OpenSpec change: acp-notification-batching Co-authored-by: Sisyphus <clio-agent@sisyphuslabs.ai> * refactor(acp): address PR #68 review feedback - Remove parameter (YAGNI — no real use case) - Move benchmark script from tests/ to scripts/ to avoid pytest collection - Revert unrelated CI fix from test_from_config_capabilities_not_duplicated - Add defensive debug log when _tool_call_inputs cache misses on ToolReturnPart * fix(test): restore monkeypatch.setenv for OPENAI_API_KEY in test_from_config_capabilities_not_duplicated CI environment has no OPENAI_API_KEY set; the setenv is required for the test that creates a NativeAgentConfig with model=openai:gpt-4o-mini. --------- Co-authored-by: Sisyphus <clio-agent@sisyphuslabs.ai>
…sage API (#149) * fix(opencode): update tool input from ToolCallProgressEvent When ToolCallStartEvent arrives before tool arguments are fully streamed, ctx stores an empty dict as tool_input. Subsequent ToolCallProgressEvent carries the complete event_tool_input but _process_tool_progress ignored it, reading the stale empty value from ctx instead. This caused tool call parameters to always appear empty in the session message API. Fix: update ctx with event_tool_input when it differs from the stored value, before constructing the tool state. Closes #148 * fix(opencode): convert event_tool_input to camelCase before comparison Address Gemini review feedback: comparing raw snake_case event_tool_input with camelCase current_input always evaluates to True when keys contain underscores, causing redundant ctx.set_tool_input calls on every progress event. Convert to camelCase first, then compare.
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
1 participant
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
Fixes the MCP-over-ACP elicitation passthrough failure where MCP server-initiated
elicitation/createrequests were being dropped or returning empty{}responses instead of the actual elicitation result.Root Cause
When an MCP server sent
elicitation/createthrough the ACP channel:ext_method("mcp/message")returned{}immediately instead of awaiting the inner MCP resultsend_to_client()forwarded the MCP response back to the ACP client as a new request, creating a fake JSON-RPC responseFix
AcpMcpConnection (
acp_mcp_manager.py)_pending_client_requests) for tracking client-initiated requestsregister_pending_request()- creates a Future for awaiting responsesfulfill_pending_request()- resolves pending Futures when responses arrive viasend_to_client()send_to_client()now checks if incoming messages are responses and fulfills pending requests before forwardingAgentPoolACPAgent (
acp_agent.py)ext_method("mcp/message")now synchronously awaits responses for client-initiated requests (with"id")"id") retain existing fire-and-forget behaviorRequestErrormapping_sanitize_jsonrpc_errorfor consistent error code sanitizationTesting
Related
fix-mcp-over-acp-elicitation-passthroughdocs/rfds/mcp-over-acp.mdx