Add `--list-config-env-vars` to binaries that use the `configs` crate

[hubcio]

Problem

Operators cannot discover all supported runtime IGGY_* variables. Release builds warn and ignore unknown names.

Add the flag to iggy-server, iggy-connectors and iggy-mcp (add CLI parsing to MCP). Print sorted, deduplicated names/templates, one per stdout line, then exit 0 with empty stderr. Print no values, banners or logs. Handle it after argument parsing but before runtime creation, dotenv/config loading, credentials, plugins, filesystem changes or network activity, including with --fresh.

Scope and design

Reuse ConfigEnvMappings and provider naming rules, including nested fields, enum variants/tags, overrides and skips. Do not maintain a second config-field list or change parsing/validation behavior.

Include each binary's runtime process variables, including shared IGGY_DISPLAY_CONFIG, its config/dotenv paths and, for the server, root credentials and shard executor knobs. Separate these from scan-only allowances without removing those allowances. Exclude build-time IGGY_CI_BUILD, test/CLI-only names, other binaries' prefixes and non-IGGY_* variables. iggy-gateway-kafka remains out of scope: it does not use configs.

Templates

• Collapse only indexed vector segments to <N>, including nested indices, e.g. IGGY_CLUSTER_NODES_<N>_IP. Keep whole-value leaf vectors as single names and preserve literal digits. Document per-field index limits in help/docs.
• Include both IGGY_CONNECTORS_SINK_<KEY>_... and IGGY_CONNECTORS_SOURCE_<KEY>_... from their config mappings. <KEY> is the configured connector key uppercased. Document that these overrides require the local provider.
• Include ..._PLUGIN_CONFIG_<FIELD> for plugin overrides. <FIELD> denotes a top-level field, with underscores preserved, excluding reserved FORMAT. List ..._PLUGIN_CONFIG_FORMAT explicitly. These are passthrough templates, not a guarantee that a plugin accepts every field. Do not load plugins to enumerate them.

Acceptance

• Test mapping coverage and exclusions per binary, plus nested/leaf vectors, index bounds, enum deduplication and sink/source templates. Exercise real override parsing, including FORMAT; template matches need not be unique.
• Subprocess tests verify identical, clean output with missing/invalid config, invalid env values and dotenv files, no services/plugins available, and no startup side effects.
• Document the flag and placeholders in --help and configuration docs.

[hubcio]

@ryerraguntla @krishvishal @numinnex will kafka gateway use configs crate?

[ryerraguntla]

@hubcio as of now kafka gateway is not using configs crate. But will consider it after the functional implementation is complete.

[ParthibanRajasekaran]

@hubcio I’d like to work on this. I’ve traced the existing ConfigEnvMappings implementation and the configuration roots used by iggy-server, iggy-connectors, and iggy-mcp.

My proposed approach is to add a shared enumeration layer over the generated mappings, normalize indexed segments and connector/plugin templates, then wire the flag into each binary as an early exit before banners, dotenv/config loading, runtime creation, plugins, filesystem changes, or networking. I’ll cover the specified mapping inclusions/exclusions and subprocess behavior.

I’ll keep iggy-gateway-kafka out of scope, following @ryerraguntla’s clarification that it does not currently use the configs crate.

Since this touches the public CLI and connectors, could you please confirm that this approach matches the intended design and assign the issue to me before I begin?

[hubcio]

@ParthibanRajasekaran thanks! before i assign, two questions in your own words:

1. connectors main is #[tokio::main], so the runtime exists before Args::parse(). how do you exit before runtime creation?
2. env_mappings() comes back fully expanded and EnvVarMapping has no index or cap fields. how do you get <N> templates and per-field limits?

then i'll assign.

[ParthibanRajasekaran]

Thanks, @hubcio. These are helpful questions.

1. For connectors, I was thinking we could replace #[tokio::main] with a synchronous main. It would parse Args and handle --list-config-env-vars first, then build Tokio and run the existing async path only for normal startup. MCP could follow the same pattern, while the server already parses before creating its executor.

2. I don’t think we can safely reconstruct templates from the expanded mappings because literal numbers and generated indexes are indistinguishable, and the limits have been lost. Instead, we could have ConfigEnv generate compact template metadata from the same fields and attributes it already processes. This would preserve <N> and max_elements while leaving the existing mappings and parsing unchanged.

Connector <KEY> and plugin <FIELD> templates could then use the existing local-provider naming rules. The Kafka gateway would remain out of scope.

Does this approach align with what you had in mind?

[hubcio]

lgtm, assigned

[hubcio]

btw @ParthibanRajasekaran please join our discord if you didn't do that already :)

[ParthibanRajasekaran]

@hubcio Sure will do!