pro --help lists computer-groups twice; the registry registers it on two lines

[ktn-jamf]

jamf-cli version

main at 5c77d4d. Present in every released version that carries the resource.

Product namespace

pro (Jamf Pro / Platform API)

Auth method

not applicable — the defect is in command registration

OS / platform

All

Command run

jamf-cli pro --help

Expected behavior

Each resource appears once in the command list.

Actual behavior

computer-groups appears twice. Counted on the built binary: two rows.

Anything else?

Cause. internal/commands/pro/generated/registry.go registers the same constructor on two consecutive lines:

71:	root.AddCommand(NewComputerGroupsCmd(ctx))
72:	root.AddCommand(NewComputerGroupsCmd(ctx))

It is the only duplicate in the registry. Checked by extracting every New…Cmd(ctx) call and looking for repeats; NewComputerGroupsCmd is the sole result.

What it costs. No capability is lost, because the two subtrees are identical. Three smaller costs:

1. pro --help is wrong, and a duplicated row reads as a defect to anyone using the output.
2. Cobra's Find resolves every path under computer-groups to the first copy, so the second whole command tree is unreachable. It is built at every process start and never used.
3. It inflates any count taken by walking the command tree by one. A test that walks the tree and reports a leaf count reports 1437 where 1436 commands are reachable.

This is a generated file, so the fix belongs in the generator, not in registry.go, which make generate overwrites. The emitter is registryTemplate in generator/parser/generator.go. The likely cause is a resource reaching the registry list twice — for example surviving both a family split and a version dedupe — so the fix is to make the emitter refuse or collapse a repeated constructor rather than to delete one line by hand.

A guard would be worth more than the fix: the emitter can fail when it is about to register the same constructor twice, so the next occurrence cannot reach a release. make verify-generated cannot see this, because the duplicate is faithfully reproduced by the generator and the tree is therefore "up to date".

How it was found. #360 walks every leaf of the command tree, and its allowlist recorded pro computer-groups get as an example that "resolves to a same-named sibling". The real cause is this duplicate, so that comment sent a reader looking for an example problem. #360 corrects the comment and does not fix the registry, this being a separate generator concern.

[ktn-jamf]

Correction: this is a lost endpoint, not a duplicated help row

I filed this as a cosmetic duplicate. It is not. Verified on main (8519828):

Two spec families resolve to the same resource name and the same output file, and one overwrote the other.

• specs/ComputerGroups.yaml declares one operation, GET /v1/computer-groups.
• specs/SmartComputerGroups.yaml declares the /v2 and /v3 computer-groups/smart-group-membership/{id} family.

Both become a resource named computer-groups with GoName ComputerGroups, so both write internal/commands/pro/generated/computer_groups.go. The smart-group-membership family won:

$ grep -oE '"/v[0-9]+/[a-z0-9/{}-]*"' internal/commands/pro/generated/computer_groups.go
"/v2/computer-groups/smart-group-membership/{id}"
"/v3/computer-groups/smart-group-membership/{id}"

GET /v1/computer-groups appears in no generated command. What that means on the binary:

$ jamf-cli pro computer-groups --help
Available Commands:
  get         Get the membership of a Smart Computer Group

So pro computer-groups get is smart-group membership, and there is no pro computer-groups list at all — against an endpoint the gateway serves (/pro/v1/computer-groups is in specs/gateway/coverage.json).

The registries and the commands now disagree, because the registries are built from the parser's full resource list and so still carry the resource that lost:

• smoke_registry.go:197 — {Resource: "computer-groups", Operation: "list", Method: "GET", Path: "/v1/computer-groups"}
• backup_registry.go:108 — "computer-groups": {ListPath: "/v1/computer-groups", ...}

pro backup therefore still captures the resource, since it reads the registry rather than the command tree. Only the CLI surface lost it. The endpoint is also reachable by hand-written callers (pro_group_tools.go, pro_audit.go call FetchAllPaginated(ctx, client, "/v1/computer-groups", 100)), which is why nothing failed and why this stood.

The duplicate pro --help row I originally reported is the visible symptom: registry.go:71-72 emits one AddCommand per resource with no dedupe, so both call the single surviving constructor.

The fix belongs in the generator, not the registry

make generate exits 0 while discarding a resource. Deduping the registry would hide it. Generator.Generate's caller should refuse when two resources resolve to the same GoName or output filename — the same class of guard as the existing checkOperationNameCollisions, which catches two operations sharing a name and would have caught this had it been keyed one level up. Then resolve the collision with a resourceNameOverrides entry, where that judgement already lives.

Worth checking whether any other family is silently in this state; the GoName collision check would answer it once and for all.

[neilmartin83]

The symptom is gone; the guard this asked for is now in #381.

registry.go no longer has a repeated New…Cmd(ctx) call — checked by extracting every constructor call and looking for repeats, zero results — and pro --help lists three distinct rows: computer-groups, computer-groups-smart-groups, computer-groups-static-groups. Fixed incidentally by the path-derived resource naming work (f9e2cc43 → 1ee814f1): every version of an endpoint now lands in one resource by construction, so the two families that both derived the name computer-groups are separately named.

That left the half this issue argued was worth more than the fix. #381 adds it: CheckRegistryCollisions refuses two resources deriving one Go name (the duplicate registration, and a package that cannot declare the constructor twice) or one file name — the latter being the likelier cause and worse alone, since the second Generate overwrites the first and a whole resource's operations leave the binary silently. Called ahead of main.go's write loop as well as inside GenerateRegistry, because by the time the registry is emitted the overwrite has already happened. Classic gets the same guard, where a repeat comes from a hand-edited manifest rather than a derivation.

It refuses rather than collapsing the repeat, as suggested here: two resources deriving one identity means the grouping upstream is wrong, and deduplicating the registration would keep pro --help honest while still discarding whichever resource lost the filename race.

Closing when #381 merges.