Skip to content

fix(filters): --filter was accepted, documented, and ignored on 20 commands - #268

Draft
Denis-hamon wants to merge 1 commit into
ovh:mainfrom
Denis-hamon:fix/filter-flag-never-applied
Draft

fix(filters): --filter was accepted, documented, and ignored on 20 commands#268
Denis-hamon wants to merge 1 commit into
ovh:mainfrom
Denis-hamon:fix/filter-flag-never-applied

Conversation

@Denis-hamon

Copy link
Copy Markdown
Contributor

withFilterFlag only binds the flag to flags.GenericFilters. The filtering itself happens inside common.ManageListRequest and common.ManageListRequestNoExpand, so a command that assembles its own rows and calls display.RenderTable gets the flag, its documentation page, its shell completion — and no filtering at all.

Twenty commands were in that state, across cloud, vps and webhosting.

What changes

Eighteen list rows and now filter them, through one helper rather than the same three lines copied eighteen times.

Two do not list anything, and lose the flag instead. cloud loadbalancer log list-kinds answers a list of plain strings, which has no properties to select on; cloud storage object quota get reads the quota of one region and renders one object. Applying --filter there would only have made the lie harder to see.

Two of the eighteen filter before wrapping. They hand their list to a template inside a wrapper object, and once the list is inside an object there are no rows left to select from. That is what common.FilteredRows is for.

Verification

Five tests, each asserting the row the filter must remove. Asserting that the kept row is present would pass just as well with no filtering at all — which is how these twenty went unnoticed.

Three sabotages, three red: the helper made inert while still compiling, the flag put back on one of the two object commands, and display.RenderTable restored on one of the eighteen.

Gate: go build, go vet, make wasm, go test ./..., make doc — all green, doc pages regenerated for the two flag removals.

Two things the instruments got wrong, and how they were caught

Both by a control, not by a reading — recorded here because the numbers in this PR depend on it.

  • The first census said 27, not 20. Seven of those were correct: they delegate to a package-local helper — listNetworksByVisibility, listLoadbalancingResources — which does filter, and the analyser did not follow one level of indirection. Verified by reading both helpers, then by a positive control that breaks one and watches its two callers reappear in the census.
  • The flag-removal test first used Flags().Lookup("filter"). withFilterFlag registers on PersistentFlags, so that answers nil whether the flag is there or not: the assertion passed with the flag put back. It runs the command now, because what matters is what cobra accepts on the command line.

Scope

Based on main, independent of the BareMetal series. The same defect existed on twenty-one commands of that series and is fixed there separately; the helper added here is the same one, with the same name and body, so if both land the merge is trivial.

🤖 Generated with Claude Code

…mmands

withFilterFlag only binds the flag to flags.GenericFilters. The filtering itself
happens inside ManageListRequest and ManageListRequestNoExpand, so a command
that assembles its own rows and calls display.RenderTable gets the flag, its
documentation page, its shell completion — and no filtering. Twenty commands
were in that state, across cloud, vps and webhosting.

Eighteen of them list rows and now filter them, through one helper rather than
the same three lines copied eighteen times. Two do not list anything:
`cloud loadbalancer log list-kinds` answers a list of plain strings, which has
no properties to select on, and `cloud storage object quota get` reads the quota
of one region and renders one object. There the honest correction is to drop the
flag, not to apply it — applying it would only have made the lie harder to see.

Two of the eighteen hand their list to a template inside a wrapper object, so
they filter before the wrapping: once the list is inside an object there are no
rows left to select from. That is what FilteredRows is for.

Five tests, each asserting the row the filter must REMOVE. Asserting the kept row
is present would pass just as well with no filtering at all, which is how these
twenty went unnoticed. Three sabotages, three red.

Two things the instruments got wrong on the way, both caught by controls:

- The first census said 27. Seven of those were correct: they delegate to a
  package-local helper — listNetworksByVisibility, listLoadbalancingResources —
  which does filter, and the analyser did not follow one level of indirection.
  Verified by reading both helpers, then by a positive control that breaks one
  and watches its two callers reappear.
- The flag-removal test first looked the flag up with Flags().Lookup("filter").
  withFilterFlag registers on PersistentFlags, so that answers nil whether the
  flag is there or not: the assertion passed with the flag put back. It runs the
  command now, because what matters is what cobra accepts on the command line.

Signed-off-by: Denis Hamon <denis.hamon@ovhcloud.com>
Co-Authored-By: Claude Opus 5 (1M context) <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