Skip to content

fix(api): correct ToolUse/ToolResult correlation for session display#360

Open
tuzkier wants to merge 2 commits intoRightNow-AI:mainfrom
tuzkier:fix/tool-result-display
Open

fix(api): correct ToolUse/ToolResult correlation for session display#360
tuzkier wants to merge 2 commits intoRightNow-AI:mainfrom
tuzkier:fix/tool-result-display

Conversation

@tuzkier
Copy link

@tuzkier tuzkier commented Mar 6, 2026

Summary

In the chat UI, tool calls when expanded show empty content. Tool results were not displayed. This PR fixes the serialization logic in get_agent_session.

Root Cause

Per Anthropic protocol, ToolUse and ToolResult live in separate messages (Assistant message and User message respectively). The old code tried to attach ToolResult to tools in the same message via tools.last_mut(), which was always None for User messages.

Changes

  • Two-pass approach: build tool_use_id(msg_idx, tool_idx) map, then attach ToolResult to the correct ToolUse in a previous message
  • Add input field to tool display so expanded view shows call parameters
  • Increase result preview from 300 to 2000 chars

Testing

  • cargo clippy --workspace --all-targets -- -D warnings passes
  • cargo test --workspace passes
  • Live integration tested: start daemon, send message to agent with tools, verify expanded tool blocks show input and result in dashboard

Security

  • No new unsafe code
  • No secrets or API keys in diff
  • User input validated at boundaries

Notes

  • Does not affect agent execution; this is a display/serialization bug in get_agent_session

Wang Hanbin added 2 commits March 6, 2026 09:06
Adds a WebSocket-based DingTalk Stream channel adapter as an alternative
to the existing webhook-based DingTalk adapter.

DingTalk Stream Mode uses a long-lived WebSocket connection to the
DingTalk Gateway, eliminating the need for a public webhook endpoint.

Changes:
- `openfang-types`: add `DingTalkStreamConfig` struct and wire into
  `ChannelsConfig` alongside the existing `DingTalkConfig`
- `openfang-channels`: implement `DingTalkStreamAdapter` (WebSocket
  connection management, ping/pong, token refresh, send via batchSend API)
- `openfang-api`: register `dingtalk_stream` in the channel registry,
  `is_channel_configured`, and `channel_config_values`
- `openfang-api`: wire adapter startup in `channel_bridge.rs`
- `openfang-cli`: add `dingtalk_stream` entry to the TUI channels list

Configuration:
```toml
[channels.dingtalk_stream]
app_key_env = "DINGTALK_APP_KEY"      # Enterprise Internal App Key
app_secret_env = "DINGTALK_APP_SECRET" # Enterprise Internal App Secret
robot_code_env = "DINGTALK_ROBOT_CODE" # optional, defaults to app_key
```

Requires an Enterprise Internal App in the DingTalk Open Platform with
Stream Mode enabled. No public endpoint needed.

Made-with: Cursor
ToolUse and ToolResult live in separate messages (Assistant then User) per
Anthropic protocol. The old code tried to attach results to tools in the
same message, so ToolResult was silently discarded.

Two-pass approach: build tool_use_id→(msg_idx,tool_idx) map, then when
processing ToolResult blocks, attach to the correct ToolUse in a previous
message. Also adds 'input' field and increases result preview to 2000 chars.

Made-with: Cursor
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant