OpenViking

This error occurs on OpenViking main (commit 54d4c0fac, v0.5.2.1+38 / 0.5.3.dev40) where ov compile silently skips the final review stage and reports the warning "Final review incomplete; publishing original artifacts" in result.warnings.

**Root cause:** PR #6364 updated AgentLoop in bot/vikingbot/agent/loop.py to call the preview hook with a new keyword argument preserve_complete, but the Compile pipeline's custom hook in bot/vikingbot/compile/pipeline_agent.py (line ~55) still uses the old two-parameter signature, so every preview call raises a TypeError that the pipeline swallows.

**Fix:** Edit bot/vikingbot/compile/pipeline_agent.py and update the hook signature to accept the new flag (Compile keeps child tool results complete unconditionally, so the flag can be ignored):

async def complete_tool_result(result, session_key, preserve_complete: bool = False):
    """Compile keeps child tool results complete unconditionally; the flag is
    accepted for signature parity with the AgentLoop preview hook."""
    return result

Then restart openviking-server and re-run ov compile. Verified result: task completes with warnings: [] and the final review stage executes normally.

The plugin sends the shared default keep_recent_count: 10, so sessions with fewer than 10 messages retain all messages in the recent tail during the final dispose() commit and are never archived. For harnesses that manage their own context, such as DSH, set the value to 0 for the end-of-session commit. Temporary workaround: run with OPENVIKING_COMMIT_KEEP_RECENT_COUNT=0. In code, change the DSH final commit in examples/dsh-memory-plugin/runtime.mjs to send keep_recent_count: 0; the same fix applies to the token-threshold commits in Claude Code and Codex auto-capture.mjs. Plugins where OpenViking manages context should keep the configurable tail. Update to a release containing PR "fix(plugins): archive every message on session commit."

This affects OpenViking 0.4.23 when a compile task was created without the optional --from flag. The Studio row renderer checks r?.from.length, but does not guard from, so a task with meta.request.from missing crashes the entire /studio/compile route.

Temporary workaround: open the Compile page with a filter that excludes the offending task, for example:

/studio/compile?status=completed

If the broken task itself is completed, use another status filter or a query that matches nothing:

/studio/compile?q=__no_match__

The task API is healthy; the failure is only in Studio rendering.

Permanent fix: upgrade to a release containing the PR fix(studio): normalize missing compile sources, or normalize missing/null source lists at the Studio API boundary:

const from = r?.from ?? [];
from.length ? from.map(/* render source */) : "—";

The minimal frontend-safe guard is:

r?.from?.length ? r.from.map(/* render source */) : "—"

This is a false-positive when OpenViking registers through Hermes' memory-provider lifecycle instead of the generic hook registry. In the OpenViking Hermes plugin manifest, remove on_session_end from the declared hooks list. Do not remove OpenVikingMemoryProvider.on_session_end() or change ctx.register_memory_provider(OpenVikingMemoryProvider()); Hermes still calls session-end commits through the MemoryProvider lifecycle. Reload/reinstall the plugin, then run hermes plugins doctor openviking again. If session commits succeed while using OpenViking plugin 2.0.1 with Hermes 0.21.5, the warning can safely be ignored until the manifest fix is installed.

Upgrade to a source revision or release containing plugin PR #5661, which fixes examples/memory-plugin-shared/lib/ov-http.mjs, plus the companion fix for the openclaw and pi-experimental clients. If pinned to commit d9352f2a8bac78cbf4ed08b26543d22adcdd4c93, cherry-pick those changes.

The defect is in the broad catch around response.json(): it converts body-read transport failures into invalid/empty JSON handling. The fix must rethrow abort/network/stream errors so the existing outer handler returns:

{ ok: false, status: 0, result: null }

and isRetryableFailure(result) returns true. For owned timeouts, the original error must keep error.name === "AbortError" and error.aborted === true.

Use a guard conceptually like:

try {
  result = await response.json();
} catch (err) {
  if (
    err?.name === "AbortError" ||
    err?.aborted === true ||
    err?.cause?.code === "UND_ERR_SOCKET"
  ) {
    throw err; // Let the outer transport handler classify and retry it.
  }

  // Keep existing handling only for a complete, malformed, or empty JSON body.
}

Do not use requireJsonBody: true as a workaround: strict mode changes the symptom to a non-retryable HTTP 200 empty or invalid JSON response failure. After the patch, normal successful responses, HTTP errors, and complete malformed/empty JSON bodies retain their previous behavior; only stalls, resets, aborts, and broken streams while reading the body become retryable status-0 transport failures.