Gate /internal/config_toml on runtime DB mode + add zero-config E2E by AntoineToussaint · Pull Request #7362 · tensorzero/tensorzero · GitHub
Skip to content

Gate /internal/config_toml on runtime DB mode + add zero-config E2E#7362

Open
AntoineToussaint wants to merge 2 commits intodb-config-bootfrom
db-config-rest-zero-config
Open

Gate /internal/config_toml on runtime DB mode + add zero-config E2E#7362
AntoineToussaint wants to merge 2 commits intodb-config-bootfrom
db-config-rest-zero-config

Conversation

@AntoineToussaint
Copy link
Copy Markdown
Member

Stacked on top of #7361.

Summary

  • Gate /internal/config_toml* on runtime DB mode, not feature flag. These three endpoints were gated on ENABLE_CONFIG_IN_DATABASE at route registration, making them unreachable even when the gateway had booted in DB-authoritative mode via the new zero-config boot path. The gate now lives in the handlers, keyed on app_state.config_in_database.
  • New zero-config E2E suite. First coverage for the "gateway boots with empty DB" path. Two tests:
    • /health returns 200 with gateway: ok and clickhouse: ok
    • GET /internal/config_toml returns a valid default document (empty collections, non-empty CAS signature) so callers can chain into /apply
  • Test infrastructure. New zero-config nextest profile + docker-compose.zero-config.yml that overrides docker-compose.e2e.yml to clear --config-file and drop the fixtures loader.

Test plan

  • cargo nextest run --profile zero-config -E 'binary(e2e) and test(zero_config::)' against the new docker-compose stack
  • Existing config-editing tests still pass under the new handler-level gating
  • Existing file-backed gateways still return NotImplemented from /internal/config_toml* with a clear message

🤖 Generated with Claude Code

AntoineToussaint and others added 2 commits April 23, 2026 13:17
The three `/internal/config_toml*` endpoints were gated on
`ENABLE_CONFIG_IN_DATABASE` at route registration. That made them
unreachable when the feature flag was off, even if the gateway had
already booted in DB-authoritative mode (which now also happens
implicitly when `TENSORZERO_POSTGRES_URL` is set and no config file is
provided).

Move the gate from the router into the handlers, keyed on
`app_state.config_in_database`. The endpoints are now available
whenever the gateway is actually using the DB as its config source,
including the zero-config boot path. File-backed gateways still get a
`NotImplemented` error with a clear explanation.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
First E2E coverage for the "gateway boots with empty DB" path:

- `zero_config_health_returns_ok` — `/health` returns 200 with both
  `gateway: ok` and `clickhouse: ok` and the expected version header.
- `zero_config_get_config_toml_returns_defaults` — `GET /internal/config_toml`
  returns a valid default document: non-empty TOML with only the default
  singletons, no user-defined function/model/tool/metric blocks, empty
  `path_contents`, and a non-empty CAS signature and hash.

These assertions establish the baseline that downstream REST-bootstrap
tests will build on. Includes:
- new `zero_config` test module, excluded from the main `e2e` profile
- `[profile.zero-config]` nextest profile
- `docker-compose.zero-config.yml` that overrides `docker-compose.e2e.yml`
  to clear the `--config-file` arg and drop the fixtures loader, so the
  gateway boots against a migrated-but-empty Postgres database

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant