admin orgs add-member sends 'org' but Carbon requires 'org_name' (+ is_owner is required, + the admin subcommand is missing from the build)

Overview Files Skills Discover Packages Releases Dependencies Issues Breadcrumbs Pull Requests Activity

Closed bug report

John Lauer · 2mo ago ·closed by Colby Knox

1. `admin orgs add-member` sends `org`, but Carbon requires `org_name`

The request never reaches the real handler; it dies in deserialization.

Verified today by probing the API directly against a nonexistent org, so nothing could be mutated:

POST /admin/orgs/add-member  {"org":"zzz-not-a-real-org-probe","username":"zzz-not-a-real-user"}
  -> Failed to deserialize the JSON body into the target type: missing field `org_name`

POST /admin/orgs/add-member  {"org_name":"zzz...","username":"zzz..."}
  -> Failed to deserialize the JSON body into the target type: missing field `is_owner`

POST /admin/orgs/add-member  {"org_name":"zzz...","username":"zzz...","is_owner":false}
  -> {"error":"ORG_NOT_FOUND"}      <- correct shape, reached the handler

So the contract is {org_name, username, is_owner}, and is_owner is required, not optional. The CLI sends org and (as far as I can tell) omits is_owner, so the command cannot succeed regardless of arguments.

Carbon's error messages here are genuinely good: they name the exact missing field. The fix is just to match them.

2. The `admin` subcommand is missing entirely from the installed build

$ adom-cli admin orgs add-member --help
error: unrecognized subcommand 'admin'

adom-cli --help shows no admin command at all on this container's build, so I could not verify #1 against the CLI itself, only against the API. Either the subcommand was dropped, is feature-gated, or lives under a path the help tree does not advertise. Worth confirming which, because the skill docs reference adom-cli carbon admin orgs add-member.

3. Previously observed, NOT re-verified: USER_NOT_A_MEMBER for a real member

Earlier this week the admin add-member path returned USER_NOT_A_MEMBER for a user who is a member of the org. I could not re-test that today without mutating a real org, so treat it as a lead rather than a confirmed bug. If #1 is fixed, it is worth re-checking whether this was just the deserialization failure surfacing under a misleading error.

4. `invitation-respond` omits `action`

Also previously observed and not re-verified today: the invitation-respond call does not send the action field the API expects (accept/decline).

Context: found while building the Organizations page in Hydrogen Desktop, which needs the org roster with roles. For anyone hitting the same thing, the role-bearing endpoint is GET /orgs/<org>/memberships (with is_owner), not /orgs/<org>/members (no role field at all). Those two names are one character apart and it costs people real time. Documented in the carbon-api skill in the adom/adom bundle.

2 Replies

Colby Knox · 2mo ago ·edited

Diagnosed all four items today. Point by point:

1. admin orgs add-member sends org instead of org_name: not a CLI bug. The command has sent {org_name, username, is_owner} (all three, is_owner always included) since it was added. Verified with your own probe technique against the current build:

adom-cli carbon admin orgs add-member --org zzz-not-a-real-org-probe --username zzz-not-a-real-user
  -> {"error":"ORG_NOT_FOUND"}

ORG_NOT_FOUND is the real handler answering, so the request deserializes fine. Your API probes correctly characterized the server contract, but the CLI already matches it. (The carbon-api skill's line saying "the CLI sends org" should be corrected; the transcript right below it, where the CLI run reaches the handler and gets USER_NOT_A_MEMBER, is the actual behavior.)

2. The admin subcommand is not missing, it is nested under carbon. The path is adom-cli carbon admin orgs add-member, matching the skill docs you referenced. Top-level adom-cli admin has never existed, which is why adom-cli --help does not show it; adom-cli carbon --help does. Every tagged release contains it, so no build on any container should lack it.

3. USER_NOT_A_MEMBER for a real member: confirmed, but it is server-side in Carbon. With the correct contract sent via curl (no CLI involved), real members of adom (kyle, whose membership is public, plus a second member whose membership is private, so not named here) still get USER_NOT_A_MEMBER while a nonexistent username gets USER_NOT_FOUND. So the endpoint resolves users fine and fails its membership check. Nothing the CLI can do; this needs a Carbon-side fix. Until then there is no working admin path to promote an existing member (the owner-driven path, PATCH /orgs/<org>/memberships/<user> with {"is_owner": true} by an existing owner, still works).

4. invitation-respond omits action: confirmed and fixed. The CLI sent {"accept": bool} where Carbon wants {"action": "accept"|"decline"}, so every call died with 422 missing field 'action'. Fixed in https://github.com/adom-inc/adom-cli/pull/10 (v0.5.13): both the default accept and --decline now reach the real handler (probe at a nonexistent org returns ORG_NOT_FOUND instead of the 422).

Will update here when 0.5.13 is released and the wiki package is republished.

Colby Knox · 2mo ago

Shipped. PR #10 is merged, v0.5.13 is on GitHub (https://github.com/adom-inc/adom-cli/releases/tag/v0.5.13), and the wiki package is republished as 4.0.6 with the 0.5.13 binary, so adom-wiki pkg install adom/adom-cli now gets the fix.

Closing since everything actionable in this CLI is done: item 4 fixed, items 1 and 2 were not CLI bugs (correct contract already sent; the command lives at adom-cli carbon admin orgs add-member). Item 3, the broken membership check behind USER_NOT_A_MEMBER, is server-side and needs to be filed against Carbon itself. Feel free to reopen if the fixed invitation-respond still misbehaves against a real invitation.

adom-cli