Summary
Two related config problems found while wiring the Verified Completions snapshot test (#81) into the harness.
1. Documented env vars crash the server in --config mode
Config::from_file merges all INPUTLAYER_* environment variables and rejects any that do not map to a config field. But the server itself documents and reads env vars that are NOT config fields, via std::env (INPUTLAYER_BOOTSTRAP_API_KEY in src/protocol/handler.rs, INPUTLAYER_ADMIN_PASSWORD). Result: a server started with --config and one of its own documented env vars set fails at startup:
$ INPUTLAYER_BOOTSTRAP_API_KEY=x inputlayer-server --config config.toml
ERROR: Failed to parse config from config.toml: unknown field: found `bootstrap_api_key`,
expected `one of `storage`, `optimization`, `logging`, `http`` for key "BOOTSTRAP_API_KEY"
in `INPUTLAYER_` environment variable(s)
The same applies to any other INPUTLAYER_* var in the environment (INPUTLAYER_API_KEY, INPUTLAYER_TEST_PORT if a CI runner exports it, etc.). The snapshot test harness now works around this by launching the server with a scrubbed environment (scripts/run_snapshot_tests.sh, start_server), but the collision will bite anyone combining a config file with the documented auth env vars, e.g. in Docker.
Suggested direction: either give the auth env vars config-field homes (e.g. http.auth.bootstrap_api_key) so figment accepts them, or stop rejecting unknown keys from the env source specifically (keep strict parsing for the TOML file).
2. Default startup path ignores env overrides entirely, and the template is stale
Without --config, the server prints "Using default configuration" and uses Config::default() directly - the INPUTLAYER_STORAGE__DATA_DIR-style overrides advertised at the top of config.toml do nothing on this path (src/bin/server.rs). And the shipped config.toml template no longer parses against the current schema:
[http.auth] enabled = false - field does not exist (rejected with unknown field)enable_wal = false vs code default trueenable_boolean_specialization = false vs code default true[optimization] and [logging] are required by from_file but the docs read as if sections are optional
Repro: inputlayer-server --config config.toml with the repo's own template fails to parse.
Impact
Low urgency but confusing: the three config mechanisms (defaults, file, env) disagree with each other and with the docs. Cost me about an hour of head-scratching during #81 validation; will do the same to any operator.
Summary
Two related config problems found while wiring the Verified Completions snapshot test (#81) into the harness.
1. Documented env vars crash the server in --config mode
Config::from_filemerges allINPUTLAYER_*environment variables and rejects any that do not map to a config field. But the server itself documents and reads env vars that are NOT config fields, viastd::env(INPUTLAYER_BOOTSTRAP_API_KEYin src/protocol/handler.rs,INPUTLAYER_ADMIN_PASSWORD). Result: a server started with--configand one of its own documented env vars set fails at startup:The same applies to any other
INPUTLAYER_*var in the environment (INPUTLAYER_API_KEY,INPUTLAYER_TEST_PORTif a CI runner exports it, etc.). The snapshot test harness now works around this by launching the server with a scrubbed environment (scripts/run_snapshot_tests.sh, start_server), but the collision will bite anyone combining a config file with the documented auth env vars, e.g. in Docker.Suggested direction: either give the auth env vars config-field homes (e.g.
http.auth.bootstrap_api_key) so figment accepts them, or stop rejecting unknown keys from the env source specifically (keep strict parsing for the TOML file).2. Default startup path ignores env overrides entirely, and the template is stale
Without
--config, the server prints "Using default configuration" and usesConfig::default()directly - theINPUTLAYER_STORAGE__DATA_DIR-style overrides advertised at the top of config.toml do nothing on this path (src/bin/server.rs). And the shippedconfig.tomltemplate no longer parses against the current schema:[http.auth] enabled = false- field does not exist (rejected with unknown field)enable_wal = falsevs code defaulttrueenable_boolean_specialization = falsevs code defaulttrue[optimization]and[logging]are required by from_file but the docs read as if sections are optionalRepro:
inputlayer-server --config config.tomlwith the repo's own template fails to parse.Impact
Low urgency but confusing: the three config mechanisms (defaults, file, env) disagree with each other and with the docs. Cost me about an hour of head-scratching during #81 validation; will do the same to any operator.