Skip to content

Remove KNOWN_UPSTREAM_FLAG_COLLISIONS override once @elastic/schemas disambiguates _version/version #503

Description

@JoshMock

Summary

src/lib/json-schema-args.ts carries a static allowlist, KNOWN_UPSTREAM_FLAG_COLLISIONS, that exempts one CLI flag from the otherwise global rule that every top-level schema field maps to a unique kebab-case flag (and that any duplicate is a hard error).

const KNOWN_UPSTREAM_FLAG_COLLISIONS = new Set(['version'])

The exception was introduced on the schemas-pkg branch (#472), alongside the fail-loudly collision check itself. It is not present on main.

Why it exists

Three Kibana request schemas in @elastic/schemas declare both _version and version as top-level input fields. Both kebab-case to version:

  • security-exceptions-api.update-exception-list.request.json
  • security-lists-api.patch-list.request.json
  • security-lists-api.update-list.request.json

Without the allowlist, registration throws for those commands. With it, _version (the optimistic-concurrency-control field) is seen first and keeps --version; version gets no CLI flag and is only reachable via stdin / --input-file body passthrough.

Current state

Verified against @elastic/schemas 0.5.1: the collision is still present, so the override cannot simply be deleted today. A repo-wide scan of all 6062 schema JSON files found no other top-level kebab-case collisions requiring an exception.

For contrast, the Kibana path-parameter allowlist that used to live in src/kb/register.ts was removable under 0.5.1 and has been dropped — this one is the sole remaining schema-driven override.

Impact

On those three commands, version violates the project rule that every top-level schema field has a corresponding CLI flag. Agents introspecting via --help --json see the field in the schema but cannot set it with a flag.

Proposed resolution (follow-up to #472)

  1. Fix upstream in @elastic/schemas: _version (OCC) and version (list/exception-list document version) are distinct concepts and should not project onto the same CLI flag. Rename or disambiguate one of them.
  2. Once upstream ships, bump the dependency, then delete KNOWN_UPSTREAM_FLAG_COLLISIONS and both KNOWN_UPSTREAM_FLAG_COLLISIONS.has(flag) guards in extractSchemaArgs. Unreviewed collisions throw by design, so removal restores full enforcement with no further changes.

If an upstream fix is not viable, the alternative is a CLI-side disambiguation strategy (e.g. suffixing the later-seen key) so no field is left without a flag — but that changes flag naming and should be decided explicitly rather than by allowlist.

Blocked on

#472 merging first.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions