Skip to content

--set duplicate key silently last-wins — warn? #200

Description

@dean0x

Repeated --set key=... arguments silently accept the last value without warning, which can hide user mistakes.

Current behavior: mds build --set x=1 --set x=2 silently uses x=2.

Open question: Should the CLI warn about duplicate keys? What's the expected UX when a user accidentally specifies the same variable twice?

Deferred from the v0.4.0 dogfooding remediation (PR #196) -- flagged during the 2026-07-17 dogfooding campaign; deliberately not implemented there pending design discussion.


Reference-corrected against main at 6d41777. This is an open design question awaiting an owner ruling, not implementation work -- there is no "done" state until the UX is decided.

Current behaviour verified unchanged: crates/mds-cli/src/build.rs:551-556 inserts each --set pair straight into a HashMap, so repeated keys silently last-win with no warning. The rustdoc at build.rs:525-527 states last-wins as the intended contract.

Adjacent work that landed but does not close this: #152 added cross-flag duplicate rejection (build.rs:539-547, error variable '{key}' is set by both --set and --set-string; tests at :1942, :1962). That covers --set x=1 --set-string x=2; it does not cover --set x=1 --set x=2, which is what this issue is about.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or requestquestionFurther information is requested

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions