C.W.K.
Stream
Lesson 04 of 04 · published

No Silent Fallback

~10 min · no-silent-fallback, honesty, degradation, api-design

Level 0Unlit Wick
0 XP0/33 lessons0/12 achievements
0/100 XP to next level100 XP to go0% complete
"A worse result that looks like a normal result is more dangerous than an error, because you'll trust it."

The Quiet Lie

Here's the failure mode that erodes trust the fastest. You ask for the best search — keyword and vectors fused, reranked. The vector server is down. A lazy engine catches the error, quietly returns keyword-only results, and formats them exactly like a full result. You have no idea anything was missing. You make a decision based on a half-search you believed was a whole one. The engine didn't crash; it lied by omission, and that's worse, because a crash you'd have noticed.

Two Honest Signals

Lantern refuses the quiet lie with two explicit signals:

  • Unwired or unsupported modes return an error — a clear not implemented rather than a pretend result. If you ask for something the engine can't do, it says so, loudly.
  • Partial results declare their gaps — when hybrid search can only run its keyword half, it returns those results plus a degraded field naming exactly what was skipped. The result is honest about its own incompleteness.

Either way, the caller always knows the true shape of what it got.

Why Silence Is Worse Than Failure

A visible failure is a decision point: you can retry, wait, warn the user, or fall back on purpose with your eyes open. A silent degradation steals that decision. It hands you a downgraded answer wearing the costume of a full one and lets you build on it. The bug it causes surfaces far away, much later, and is nearly impossible to trace back — because at the moment of the lie, everything looked fine.

Degrade loudly or not at all. Falling back to a lesser result can be the right move — but only when the caller is told. Bake the degradation into the response itself: a field that says 'this is partial, and here's what's missing.' Silent fallback trades a visible, handleable failure for an invisible, untraceable one. Never make that trade.

The Envelope Carries the Truth

The mechanism is simple: every response is an envelope, not a bare list. It holds the results and a small record of how they were produced — which mode actually ran, what was skipped, whether anything degraded. Most of the time that record is empty and nobody looks. On the day the vector server is down, that record is the difference between a caller that quietly trusts a half-answer and one that knows to say 'heads up, this search was keyword-only.'

Code

The envelope tells the truth about what actually ran·json
// A healthy hybrid search — nothing degraded.
{
  "mode": "hybrid",
  "results": [ /* fused keyword + vector hits, reranked */ ],
  "degraded": []
}

// The SAME endpoint, vector server down. Note it does not pretend.
{
  "mode": "hybrid",
  "results": [ /* keyword-only hits */ ],
  "degraded": ["vectors_unavailable"]   // <-- the caller knows it's partial
}

// An unsupported mode does not fake it — it errors, loudly:
// HTTP 501  { "error": "mode 'semantic-graph' is not implemented" }

External links

Exercise

Find a tool or API you use that might quietly give you a worse result under some failure — a search that falls back, a sync that partially completes, an autocomplete that silently uses stale data. How would you even know it happened? Design the one field it should return to make the degradation visible, and describe how a caller would react differently once it could see that field.
Hint
The question that exposes silent fallback is always 'how would I know?' If the answer is 'I wouldn't', the system is degrading in silence — and the fix is a single honest field in the response that names what was missing.

Progress

Progress is local-only — sign in to sync across devices.
Spotted a bug or have feedback on this page?Report an Issue

Comments 0

🔔 Reply notifications (sign in)
Sign inPlease sign in to comment.

No comments yet — be the first.