Summary
A library reads four unnamespaced process-global environment variables:
INDEX_EMBED_BATCH_SIZE
INDEX_MAX_CHUNK_LINES
INDEX_WINDOW_SIZE
INDEX_WINDOW_STEP
plus LCI_CODEGRAPH_IGNORE_GLOBS, which is namespaced — so the crate is already inconsistent with
itself.
INDEX_* is a generic prefix. Any host that embeds this crate inherits a claim on it, and an operator
setting INDEX_WINDOW_SIZE for something else in the same process silently reconfigures this crate's
chunker. The failure is quiet: chunk sizes change, nothing errors, and the cause is a variable name
that appears nowhere in the host's own configuration.
Current behaviour
IndexTuning::from_env and walk_checkout_from_env read the bare names. from_env also swallows
unparseable values, falling back to the default — so a typo'd or conflicting value is invisible.
This is a reasonable design for the monorepo the crate was extracted from, where INDEX_* was that
service's own namespace. It reads differently for a crate published on crates.io and embedded by
callers who have never heard of that service.
Suggested direction
Prefix them to match the one variable that already is:
LCI_CODEGRAPH_EMBED_BATCH_SIZE
LCI_CODEGRAPH_MAX_CHUNK_LINES
LCI_CODEGRAPH_WINDOW_SIZE
LCI_CODEGRAPH_WINDOW_STEP
The crate is at 0.1.0 and unpublished, so this can be a straight rename with no compatibility
shim — which is the right call rather than reading both names for a release. If it does ship before
this lands, it is a breaking change and belongs in a 0.2.0.
Worth considering alongside: log at info when a variable is read and applied, and at warn when one
is present but unparseable. from_env's silent fallback is the part most likely to waste somebody's
afternoon, independent of the naming.
Also worth a look
walk_checkout_from_env reads tuning and ignore globs from the environment but takes build_graph as
a plain argument. That split is defensible — it is the one option with a real cost — but it is
surprising enough that it deserves a sentence in the function's docs saying why, rather than leaving
a reader to wonder whether it was an oversight.
Acceptance
Provenance
Noticed while wiring the crate into a service that namespaces all of its own configuration under a
single prefix, where INDEX_* would have been the only unprefixed variables in the deployment.
AI usage: drafted with Claude (Claude Code). Variable names and the from_env fallback behaviour read
from src/tuning.rs and the README against main @ 293d12f.
Summary
A library reads four unnamespaced process-global environment variables:
plus
LCI_CODEGRAPH_IGNORE_GLOBS, which is namespaced — so the crate is already inconsistent withitself.
INDEX_*is a generic prefix. Any host that embeds this crate inherits a claim on it, and an operatorsetting
INDEX_WINDOW_SIZEfor something else in the same process silently reconfigures this crate'schunker. The failure is quiet: chunk sizes change, nothing errors, and the cause is a variable name
that appears nowhere in the host's own configuration.
Current behaviour
IndexTuning::from_envandwalk_checkout_from_envread the bare names.from_envalso swallowsunparseable values, falling back to the default — so a typo'd or conflicting value is invisible.
This is a reasonable design for the monorepo the crate was extracted from, where
INDEX_*was thatservice's own namespace. It reads differently for a crate published on crates.io and embedded by
callers who have never heard of that service.
Suggested direction
Prefix them to match the one variable that already is:
The crate is at
0.1.0and unpublished, so this can be a straight rename with no compatibilityshim — which is the right call rather than reading both names for a release. If it does ship before
this lands, it is a breaking change and belongs in a
0.2.0.Worth considering alongside: log at
infowhen a variable is read and applied, and atwarnwhen oneis present but unparseable.
from_env's silent fallback is the part most likely to waste somebody'safternoon, independent of the naming.
Also worth a look
walk_checkout_from_envreads tuning and ignore globs from the environment but takesbuild_graphasa plain argument. That split is defensible — it is the one option with a real cost — but it is
surprising enough that it deserves a sentence in the function's docs saying why, rather than leaving
a reader to wonder whether it was an oversight.
Acceptance
LCI_CODEGRAPH_prefix.IndexTuning::from_envrustdoc match the code.Provenance
Noticed while wiring the crate into a service that namespaces all of its own configuration under a
single prefix, where
INDEX_*would have been the only unprefixed variables in the deployment.AI usage: drafted with Claude (Claude Code). Variable names and the
from_envfallback behaviour readfrom
src/tuning.rsand the README againstmain@293d12f.