[Bug]: VLM/abstract-generation failures are silently swallowed — status healthy, queue 0 errors, retrieval degrades to ~99% zero-result

Summary

When the configured VLM is unreachable (e.g. model not pulled in Ollama), abstract/overview generation fails for every ingested resource — yet ov status reports all components healthy, ov observer queue shows 0 errors in every queue, and nothing warns the operator. The deployment silently degrades: all resources end up with "No abstract available" / "Directory overview is not generated", and the retrieval zero-result rate climbs to ~99% with no visible cause.

Environment

• OpenViking server 0.4.18 (local vectordb backend), openviking-sdk 0.1.10
• Embedding: Ollama nomic-embed-text (768d) at http://127.0.0.1:11441/v1
• VLM: Ollama llama3.2-vision at http://127.0.0.1:11441
• Deployment: systemd user service, auth_mode=dev

What happened (our misconfiguration, but that's the point)

llama3.2-vision was configured in ov.conf but never actually pulled into Ollama. Every abstract/overview generation call then failed:

litellm.exceptions.APIConnectionError: OllamaException - {"error":"model 'llama3.2-vision' not found"}

This error appears 600+ times in the service journal. Meanwhile:

• add_resource succeeded and resources were ingested normally (queue: AddResource processed 3, errors 0)
• ov status → all components healthy (queue, vikingdb, models, retrieval, filesystem); models component even reports "VLM + embedding available"
• ov observer queue → 0 errors in every queue (Embedding, Semantic, AddResource, SessionCommit, ...)
• Every ingested file shows No abstract available; every directory shows [Directory overview is not generated]
• Retrieval silently degraded: 93 queries, 98.9% zero-result rate — with no signal pointing at the dead abstract pipeline

The only way to discover the failure was to manually read the systemd journal and correlate it with the retrieval stats.

Why this matters

L0/L1 abstracts are the backbone of the layered-loading design — without them, retrieval is effectively blind. A missing/misconfigured VLM is probably one of the most common deployment mistakes (model name typo, Ollama not pulled, wrong api_base, VLM OOM). Today the system absorbs this failure completely silently, so operators can run for weeks believing memory works while every recall returns nothing.

Suggestions

1. Startup validation: at server start, probe the configured VLM + embedding models with a minimal real call (e.g. 1-token completion / 1-embed). If unreachable, log a prominent warning and reflect it in ov status (component models → degraded, with the actual error).
2. Count abstract-generation failures: route VLM/abstract task failures into the queue Errors column (or a dedicated counter) instead of swallowing them after retry.
3. Health from outcomes, not just connectivity: the models component currently reports "VLM + embedding available" based on configuration/reachability; it should factor in recent call success rate.
4. Retrieval anomaly surfacing: a sustained zero-result rate above a threshold (say >90% over N queries) deserves a warning in ov status, pointing operators at likely causes (missing abstracts, embedding mismatch).

Happy to provide full journal excerpts or test a patch on our deployment.