Skip to content

fix: reject duplicate if-block conditions within the same list key - #155

Open
Tobias-Fischer wants to merge 1 commit into
RoboStack:masterfrom
Tobias-Fischer:fix/sort-vinca-lists-duplicate-conditions
Open

fix: reject duplicate if-block conditions within the same list key#155
Tobias-Fischer wants to merge 1 commit into
RoboStack:masterfrom
Tobias-Fischer:fix/sort-vinca-lists-duplicate-conditions

Conversation

@Tobias-Fischer

Copy link
Copy Markdown
Contributor

Summary

  • Two "- if:" blocks for the same condition under one list key (e.g. two separate "if: win" blocks in packages_select_by_deps) are never wrong on their own, but they're a standing foot-gun downstream: a future addition can land in the "wrong" one by accident, nothing merges the two, and the same package can end up skipped from one angle and not the other depending on which block someone edits later.
  • This is distinct from the adjacent-blocks bug fixed in fix: close if-block before starting a new one in sort_vinca_lists #152 — these duplicates aren't adjacent, so that fix's "close the block on a new - if: line" logic never sees them as related at all.
  • Raises DuplicateConditionError (exit 1, clean message naming the list key and condition) rather than silently merging the blocks — merging correctly needs a human to reconcile any per-item comments, since sorting the merged then: list can separate a standalone comment from the item it was meant to describe.

Motivation

Found while auditing RoboStack/ros-humble, ros-jazzy, and ros-rolling's vinca.yaml files for exactly this pattern. Humble alone had accumulated 4 separate duplicate-condition groups across ~19 blocks (mostly if: not win and if: linux) from being extended incrementally across many sessions — consolidating them by hand also surfaced live cases where a per-item comment had already drifted onto the wrong package from a previous sort, which is what motivated making the check hard-fail rather than silently reformat.

Test plan

  • pytest vinca/ — all 236 tests pass (7 in test_sort_vinca_lists.py, including 3 new ones for this change: duplicate-in-same-list raises, duplicate-across-different-list-keys is fine, different-conditions-in-same-list is fine)
  • ruff check / ruff format --check clean
  • Ran the updated checker against the already-consolidated humble/jazzy/rolling vinca.yaml files — all pass clean with no duplicates
  • Verified against a synthetic non-adjacent duplicate (- if: win ... other content ... - if: win) that it's correctly caught with a clear message

🤖 Generated with Claude Code

Two "- if:" blocks for the same condition under one list key (e.g.
two separate "if: win" blocks in packages_select_by_deps) are never
wrong on their own, but they're a standing foot-gun downstream: a
future addition can land in the "wrong" one by accident, nothing
merges the two, and the same package can end up skipped from one
angle and not the other depending on which block someone edits later.

This showed up for real across all three of RoboStack's humble/jazzy/
rolling vinca.yaml files -- humble alone had accumulated 4 separate
duplicate-condition groups across ~19 blocks (mostly "if: not win"
and "if: linux") from being extended incrementally across many
sessions, none of which the previous adjacent-block fix (RoboStack#152) would
have caught since they weren't adjacent.

Raises DuplicateConditionError (exit 1, clean message naming the list
key and condition) rather than silently merging the blocks -- merging
correctly needs a human to reconcile any per-item comments, since
sorting the merged then: list can separate a standalone comment from
the item it was meant to describe (the exact hazard RoboStack#152 fixed for
adjacent blocks, but which still applies to a comment sitting above
an item inside either of the two blocks being merged by hand).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant