Skip to content

fix: handle ChurchTools group children responses - #137

Merged
2000game merged 3 commits into
eqrm:mainfrom
bwl21:fix/adopt-group-children-response
Aug 24, 2026
Merged

2000game merged 3 commits into
eqrm:mainfrom
bwl21:fix/adopt-group-children-response

Conversation

@bwl21

@bwl21 bwl21 commented Aug 22, 2026 •

Copy link
Copy Markdown
Contributor

Summary

  • accept both direct arrays and { data: [...] } responses from the group children endpoint
  • resolve ChurchTools domain resources through domainIdentifier, with apiUrl as a fallback
  • reject unknown response shapes and propagate children-endpoint errors instead of silently treating them as empty subtrees
  • preserve recursive parent-before-child traversal, root exclusion, cycle protection, deduplication, and existing state/key behavior

Root cause

The live GET /groups/{id}/children endpoint returns domain resources. Their group ID is exposed as a numeric domainIdentifier, not as id. Although CtClient already unwraps the normal data envelope, the traversal discarded every returned child because it only inspected id.

The previous implementation also treated every 404 from the children endpoint as a leaf. The ChurchTools OpenAPI defines that response as resource not found; a real leaf is represented by a successful empty collection.

Validation

  • npm test — 810 passed, 5 skipped
  • npm run typecheck
  • npm run lint
  • node .github/scripts/docs-staleness.mjs
  • git diff --check

Fixes #136

@bwl21
bwl21 marked this pull request as ready for review August 22, 2026 17:53
@bwl21 bwl21 changed the title [codex] fix group children API responses fix: handle ChurchTools group children responses Aug 23, 2026
bwl21 and others added 2 commits August 23, 2026 11:28
Review of eqrm#137 found the new children handling reads a paginated list
endpoint with a plain `get`, so `--children-of` saw only CT's default
first page (10 rows) and never descended into the rest of a wide
Bereich — silently producing an incomplete config that `ct plan` then
reports as unmanaged groups. Same bug class as eqrm#101.

- read the endpoint with `getAll`, never a plain `get` (eqrm#101). That also
  subsumes the hand-rolled envelope normalization (`extractChildren`,
  now removed): `getAll` already absorbs both the bare-array and the
  `{ data: [...] }` page shapes, and an empty 204 body — which for a leaf
  group means "no children" rather than the hard failure it had become.
  Detecting a wholly unknown object shape goes with it; that shape has
  never been observed from CT, and shape normalization for list reads
  belongs in `CtClient`, which has its own coverage.
- prefer `domainIdentifier` over `id` when resolving a child row. For a
  domain resource (`domainType: "group"`) `domainIdentifier` is the
  authoritative group id; a sibling `id` would be the hierarchy edge's
  own id, so preferring it walks into the wrong groups with no error.
- gate the `apiUrl` fallback on `== null`, not `=== undefined`: a row of
  all-null ids with a usable `apiUrl` used to throw.
- name the failing group in both error messages instead of printing the
  literal `/groups/{id}/children` placeholder — `--children-of` walks
  whole subtrees, so "some group somewhere" is not actionable.
- restore the `collectSubtreeIds` JSDoc, which had drifted onto the
  function inserted beneath it.
Claude-Session: https://claude.ai/code/session_013f7Wx1b9m8w2AVp4HCsnot
@2000game
2000game merged commit 9962e42 into eqrm:main Aug 24, 2026
3 checks passed
@bwl21
bwl21 deleted the fix/adopt-group-children-response branch August 24, 2026 09:09
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.

fix: adopt group --children-of ignores ChurchTools domain resources

2 participants