Skip to content

[Ticket]: Library reads unnamespaced INDEX_* environment variables (and is inconsistent with its own LCI_CODEGRAPH_ prefix) #14

Description

@stephane-segning

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

  • All tuning variables share the LCI_CODEGRAPH_ prefix.
  • README's env-var table and the IndexTuning::from_env rustdoc match the code.
  • An unparseable value is surfaced (log) rather than silently defaulted.

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions