fix: skip generated CLI query flags that collide with spec parameters

[ChiragAgg5k]

The CLI generator adds --filter/--sort-*/--limit/--offset/--cursor-*/--select options to any command whose method has a queries array parameter. The new cloud usage endpoints (listEvents, listGauges) declare literal limit and offset parameters alongside queries, so the generated command binds --limit/--offset twice and Commander throws at registration:

error: "limit" cannot be bound multiple times in the same parameter list

This is what currently fails the cli (console) validation job (visible on #1653 after the 1.9.x specs sync).

getCliQueryConfig() now suppresses a generated flag group when any of its names collide with the method's own parameters, so the spec-declared options win.

Verified by generating from the current 1.9.x console spec: usage commands keep their single spec-declared --limit/--offset, bun run linux-x64 compiles, npm run build passes, and node dist/cli.cjs usage list-events --help renders correctly (with @appwrite.io/console@15.3.0 installed — the remaining validation dependency is the pin bump in #1653).

[greptile-apps]

Greptile Summary

This PR fixes a Commander.js duplicate option binding crash by suppressing auto-generated CLI query flags (--limit, --offset, --filter, --select, etc.) when they collide with a method's own spec-declared parameters. The crash was triggered by new usage endpoints (listEvents, listGauges) that declare literal limit and offset parameters alongside a queries array parameter.

• A $collides closure is added that checks the candidate flag names against $method['parameters']['all'] and returns true if any overlap is found, suppressing the entire flag group.
• $hasFilteringQueries, $hasPaginationQueries, and $hasSelectQueries each receive an additional !$collides(...) guard so only truly-unique generated flags are registered with Commander.

Confidence Score: 4/5

Safe to merge — fixes a real crash with minimal, well-scoped changes.

The crash fix is correct and the $collides closure logic is sound for the stated limit/offset use case. The all-or-nothing suppression of the filtering group is slightly broader than the minimum required, which could silently drop valid CLI flags if a future spec parameter happens to share a name with just one of the filtering flag identifiers.

src/SDK/Language/CLI.php — specifically the $hasFilteringQueries collision guard

Important Files Changed

Filename	Overview
src/SDK/Language/CLI.php	Adds collision detection in getCliQueryConfig() to suppress generated query flags that duplicate spec-declared parameter names; the filtering-group suppression is all-or-nothing which could over-suppress if only one name in the group collides.

Prompt To Fix All With AI

Fix the following 1 code review issue. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 1
src/SDK/Language/CLI.php:244
**All-or-nothing filtering suppression on partial collision**

`$collides(['filter', 'where', 'sortAsc', 'sortDesc', 'cursorAfter', 'cursorBefore'])` returns `true` if *any single* name in the list matches a spec parameter, which then suppresses the entire filtering group. If a future endpoint declares, say, a `where` parameter but none of the others, the generated `--filter`, `--sort-asc`, `--sort-desc`, `--cursor-after`, and `--cursor-before` flags would all be silently dropped even though only `--where` would have caused a Commander collision. For the immediate `limit`/`offset` case this is irrelevant, but the filtering group check could be overly aggressive for later spec additions.

_{Reviews (1): Last reviewed commit: "(fix): skip generated CLI query flags th..." | Re-trigger Greptile}

[greptile-apps]

All-or-nothing filtering suppression on partial collision

$collides(['filter', 'where', 'sortAsc', 'sortDesc', 'cursorAfter', 'cursorBefore']) returns true if any single name in the list matches a spec parameter, which then suppresses the entire filtering group. If a future endpoint declares, say, a where parameter but none of the others, the generated --filter, --sort-asc, --sort-desc, --cursor-after, and --cursor-before flags would all be silently dropped even though only --where would have caused a Commander collision. For the immediate limit/offset case this is irrelevant, but the filtering group check could be overly aggressive for later spec additions.

Prompt To Fix With AI

This is a comment left during a code review.
Path: src/SDK/Language/CLI.php
Line: 244

Comment:
**All-or-nothing filtering suppression on partial collision**

`$collides(['filter', 'where', 'sortAsc', 'sortDesc', 'cursorAfter', 'cursorBefore'])` returns `true` if *any single* name in the list matches a spec parameter, which then suppresses the entire filtering group. If a future endpoint declares, say, a `where` parameter but none of the others, the generated `--filter`, `--sort-asc`, `--sort-desc`, `--cursor-after`, and `--cursor-before` flags would all be silently dropped even though only `--where` would have caused a Commander collision. For the immediate `limit`/`offset` case this is irrelevant, but the filtering group check could be overly aggressive for later spec additions.

How can I resolve this? If you propose a fix, please make it concise.

[ChiragAgg5k]

Consolidated into #1653 so all pipelines can validate the pin bump and the flag-collision fix together.