What is a stale query parameter after reload?

A stale query parameter after reload is when search quality or latency suddenly shifts after a process restart, index reload, or redeploy because the ef, dynamic-ef bounds, result limit, or related search knobs the system is actually using no longer match the values operators thought were still in force.

Why do query-time knobs matter more after a restart than people expect?

HNSW recall is not only a property of the stored graph. At query time the engine walks with a candidate list whose size is governed by ef – either a fixed value or a dynamic value derived from the requested limit and bounds such as dynamicEfMin, dynamicEfMax, and dynamicEfFactor. Before a reload, production may have been running with a carefully raised ef, a raised dynamicEfMax, or application code that always passed an explicit high limit. After the node comes back, any of those pieces can silently revert: schema updates that lived only in a forgotten runbook, client defaults that omit the override, environment-driven default limits that differ between images, or a collection recreate that restored immutable build settings but not the mutable search settings. The graph on disk can be identical; the walk depth is not – so recall and latency look like a regression even though no vectors changed.

The failure is "stale" because something still believes yesterday’s knobs are live.

Where do stale parameters hide in the stack?

Common hiding places include application configs that hard-code an old ef or limit after the collection definition was updated the other way; feature flags or sidecar defaults that reset on pod recreate; notebooks and admin scripts that patched ef interactively without committing the change to the collection update API; load-test harnesses that used a large limit (and therefore a large dynamic ef) while production traffic uses a small default; and documentation that lists intended values that never matched what was actually persisted. Another pattern is dual paths: one service reads collection config at boot and caches it for hours, while another always fetches live settings – after a reload only one path refreshes, so A/B traffic disagrees. Operators then chase metric mismatch or insertion-order theories while the real gap is simply which ef math each path applies.

Reloads also change what "the same query" means when defaults are dynamic.

How does dynamic ef turn a limit change into a recall cliff?

When ef is set to -1, effective search depth tracks limit * dynamicEfFactor, clipped by min and max bounds. A client that stopped sending an explicit limit after a library upgrade – falling back to a lower server default – shrinks the working set even if every named HNSW field still looks unchanged in the schema dump. Conversely, a post-reload bump to QUERY_DEFAULTS_LIMIT or an accidental large limit in a new client can push dynamic ef to the ceiling and make latency spike without any graph rebuild. Filter strategy and flatSearchCutoff are mutable in the same family of settings: a restart that rolls back an ACORN-versus-sweeping experiment, or that restores a cutoff you had lowered for sparse predicates, will change filtered recall and cost while unfiltered smoke tests still pass.

Weaviate makes the durable versus ephemeral distinction clear if you know where to look.

How should you treat these knobs in Weaviate across restarts?

Persist intended search behavior in the collection definition: ef, dynamicEfMin, dynamicEfMax, dynamicEfFactor, filterStrategy, and flatSearchCutoff are mutable and survive process restart when updated through the collection config APIs – unlike one-off client overrides that vanish when a process dies. After every deploy, read the live collection config and compare it to the values your application sends on the wire; do not trust memory of a previous interactive tune. If you rely on dynamic ef, treat limit as part of the recall contract and pin it in clients. Remember that efConstruction and maxConnections are not mutable after create – a recreate "to fix search" can reset those while you only meant to restore ef. During startup, HNSW snapshots and commit-log replay restore the graph; they do not invent query parameters. Cold vector-cache fill can make the first minutes after reload slower without changing ef – measure both latency and recall before concluding the parameter itself is wrong.

Catching staleness is a config diff problem more than an ANN math problem.

How do you detect a stale query parameter after reload?

Correlate the quality cliff with a restart, rolling upgrade, or client release – not with an ingest batch. Dump collection vector-index config before and after; flag any drift in ef or dynamic-ef fields. Capture a sample of production queries’ effective limit and compare to the pre-incident baseline. Re-run a fixed eval set with the old and new effective ef (or with an explicit fixed ef) on the same index: if recall snaps back when you force the prior depth, the graph is fine and the knobs were stale. Check that every service that queries Weaviate loads config the same way after boot, and that runbooks that "temporarily raise ef" always end in a persisted collection update.

A stale query parameter after reload is yesterday’s search depth running on today’s process. Next, read "What is a filtered-query collapse?" when only predicate-constrained searches fail after a change, or "What causes a latency spike in search?" when the symptom is tail latency rather than missing neighbors.