Integrate OpenViking structured turn sync - #37251
Conversation
80d7977 to
60eac1a
Compare
|
Thanks for the update. This is much closer to what OpenViking needs: I checked it against the current OpenViking source, and the broad direction is right. I still think there are two important issues to fix before merging. First, {"type": "input_text", "text": "user message"}
{"type": "output_text", "text": "assistant answer"}With that shape, structured sync can silently drop the assistant text. For example, a turn like: [
{"role": "user", "content": [{"type": "input_text", "text": "hello"}]},
{"role": "assistant", "content": [{"type": "output_text", "text": "answer"}]},
]currently converts into only the user message in the OpenViking batch, so the assistant answer never reaches OpenViking. The clean fix is to use one Hermes-owned text extraction helper for canonical message content, or at minimum make this helper support the full set of text-bearing block types: TEXT_PART_TYPES = {"text", "input_text", "output_text", "summary_text"}I would keep the migration narrow in this PR: add or use a shared helper, wire it into OpenViking structured sync, and add regression coverage for Second, completed tool results should not be emitted as The better shape is to keep ToolParts on assistant-role messages, for example: {
"role": "assistant",
"parts": [
{"type": "text", "text": "I will inspect that."},
{
"type": "tool",
"tool_id": "call_123",
"tool_name": "shell_command",
"tool_input": {"command": "rg foo"},
"tool_output": "...",
"tool_status": "completed",
},
],
}The final assistant answer can remain a later assistant message. Consecutive assistant messages are fine here; they preserve the actual assistant tool execution followed by the final response. One smaller coverage gap: So my suggested path is:
I do not think OpenViking itself needs changes for this PR; the server-side contract already supports the structured payload. The remaining fixes are about sending the right Hermes-side shape into that contract. |
What does this PR do?
This PR fixes OpenViking turn ingestion so the memory provider persists Hermes canonical messages with their structured content instead of flattening the turn into plain user/assistant text.
Before this change,
sync_turn()only useduser_contentandassistant_content, so tool calls and tool results from the completed turn were not stored in OpenViking. Hermes already passes the full canonicalmessageslist to memory providers; this PR makes the OpenViking provider consume that message list and write it through OpenViking's structured/messages/batchAPI.Completed Hermes tool calls are stored as OpenViking
ToolParts with:tool_idtool_nametool_inputtool_outputtool_statusThis preserves the actual turn structure in OpenViking storage and keeps Hermes as the source of truth for the live transcript.
Related Issue
Related to #34763
Type of Change
Changes Made
plugins/memory/openviking/__init__.pysync_turn(messages=...)handling for Hermes canonical turn messages./messages/batchpayloads withparts.tool_callsand matchingrole=toolmessages into OpenViking ToolParts.tests/openviking_plugin/test_openviking.pyHow to Test
Run the targeted OpenViking provider tests:
Confirm the tests pass.
Observed result:
Checklist
Code
fix(scope):,feat(scope):, etc.)pytest tests/ -qand all tests passDocumentation & Housekeeping
docs/, docstrings) — or N/Acli-config.yaml.exampleif I added/changed config keys — or N/ACONTRIBUTING.mdorAGENTS.mdif I changed architecture or workflows — or N/AScreenshots / Logs