Session API reports zero message/commit counts even though archive and fallback files are written

[gervaso-assistant]

Bug description

Using OpenViking 0.3.8 through the Hermes OpenViking provider, the session HTTP/API path appears inconsistent:

• session initialization + message sync + commit requests succeed from the client side
• archive files are written under viking/default/session/.../history/archive_001/
• explicit fallback resource files are written under viking/default/resources/hermes_explicit_memories/...
• but openviking session get <session_id> -o json still reports:
  • message_count: 0
  • commit_count: 0
  • memories_extracted.total: 0
  • llm_token_usage.total_tokens: 0

This makes the session/accounting/extraction path look empty even though on-disk artifacts show the interaction was actually processed and persisted.

Environment

• OpenViking: 0.3.8
• deployment: local Linux systemd service
• auth mode: API key
• tenant scope:
  • account: default
  • user: hermes
  • agent: hermes
• embeddings: Ollama + nomic-embed-text
• VLM: Ollama + qwen2.5:1.5b

Relevant config

{
  "default_account": "default",
  "default_user": "hermes",
  "default_agent": "hermes",
  "server": {
    "host": "127.0.0.1",
    "port": 1933,
    "auth_mode": "api_key"
  },
  "embedding": {
    "dense": {
      "provider": "ollama",
      "api_base": "http://127.0.0.1:11434/v1",
      "model": "nomic-embed-text",
      "dimension": 768
    }
  },
  "vlm": {
    "provider": "ollama",
    "model": "qwen2.5:1.5b",
    "api_base": "http://127.0.0.1:11434"
  }
}

Reproduction

A minimal reproduction from the Hermes-side provider flow was:

import time, uuid, subprocess
from plugins.memory.openviking import OpenVikingMemoryProvider

token = 'ov-issue-' + uuid.uuid4().hex[:10]
session_id = 'ov-issue-session-' + uuid.uuid4().hex[:8]

p = OpenVikingMemoryProvider()
p.initialize(session_id)
p.sync_turn(f'User mentions {token}', f'Assistant acknowledges {token}')
p.on_memory_write('add', 'memory', f'Important explicit note {token}')
if p._sync_thread and p._sync_thread.is_alive():
    p._sync_thread.join(timeout=8)
if p._memwrite_thread and p._memwrite_thread.is_alive():
    p._memwrite_thread.join(timeout=8)
time.sleep(2)
p.on_session_end([])
time.sleep(3)

print(subprocess.run(['openviking', 'session', 'get', session_id, '-o', 'json'], capture_output=True, text=True).stdout)
print(subprocess.run(['openviking', 'find', token, '--limit', '5'], capture_output=True, text=True).stdout)

Concrete run:

• token: ov-issue-e4747f8f93
• session: ov-issue-session-4248eeb2

Actual session output

{"ok":true,"result":{"session_id":"ov-issue-session-4248eeb2","created_at":"2026-04-17T17:24:29.557Z","updated_at":"2026-04-17T17:24:31.624Z","message_count":0,"commit_count":0,"memories_extracted":{"profile":0,"preferences":0,"entities":0,"events":0,"cases":0,"patterns":0,"tools":0,"skills":0,"total":0},"last_commit_at":"","llm_token_usage":{"prompt_tokens":0,"completion_tokens":0,"total_tokens":0},"embedding_token_usage":{"total_tokens":0},"user":{"account_id":"default","user_id":"hermes","agent_id":"hermes"},"pending_tokens":0}}

On-disk evidence that data was actually written

Session archive exists:

• ~/.openviking/data/viking/default/session/hermes/ov-issue-session-4248eeb2/history/archive_001/.abstract.md
• ~/.openviking/data/viking/default/session/hermes/ov-issue-session-4248eeb2/history/archive_001/.overview.md

Explicit fallback memory exists and contains the token:

• ~/.openviking/data/viking/default/resources/hermes_explicit_memories/memory_1776446669592_141b117e/upload_503a18190f8141b3941b6cd586527866.md

Content:

# Hermes explicit memory

Target: memory
Session: ov-issue-session-4248eeb2
Recorded at ms: 1776446669582

Content: Important explicit note ov-issue-e4747f8f93

Expected behavior

At least one of these should be true after successful sync + commit:

1. session get reflects the real message/commit counts and token usage, or
2. the commit/session APIs should return an error if the session state is not actually materialized

Right now the API/CLI surface suggests that nothing happened, while the filesystem shows that something definitely did happen.

Why this matters

For agent integrations, this makes it very hard to tell whether the session-backed extraction path is healthy. Hermes had to add a deterministic fallback resource path because the primary session/accounting path appears successful operationally but remains zeroed in session get.

If helpful, I can also provide:

• the exact Hermes-side HTTP calls used around /api/v1/sessions/{sid}
• logs from the local OpenViking service during the reproduction