fix(signup): name the group and the likely cause when a Kanidm group write fails #112

Sammanfogat

supernaut sammanfogade 1 incheckning från fix/signup-group-write-diagnostics in i main

2026-07-30 18:37:00 +00:00

supernaut kommenterad

2026-07-30 18:16:17 +00:00

Ägare

Sign-up was broken in production for 13 days (2026-07-17..30) and the only evidence was:

[signup] Kanidm provisioning failed after person create; rolling back:
Error: group add -> 404

That names neither which group failed nor the fact that 404 is ambiguous here — which is most of why
it went unfound.

Why 404 was misleading

Kanidm returns 404 for a denied write, not 403 — it will not confirm the existence of an entry the
caller may not manage. So the 404 had two very different causes and the message implied the wrong one.

The actual cause was the entry-managed-by delegation: sign-up moved from tier_basic to
tier_participant (ADR 0029) and gained tier_trial (ADR 0036), but that delegation is a manual
kanidm group set-entry-manager step and was never re-run — so the portal was denied member-write on
the only groups it writes.

The change

groupWriteError() now produces:

group add tier_participant -> 404 (group missing, OR member-write not delegated to this service
account — Kanidm returns 404, not 403, for a denied write; check `entry_managed_by` on the group)

Applied to both the tier group and the Forgejo access group, which shared the same uninformative
message. The access group is worth the same treatment: a person missing from forgejo_users gets zero
OIDC scopes, so every Forgejo login is refused and no account is ever JIT-created — silent-but-broken
in a different way.

Tests

Three regression tests: the group name is present; a 404 explains the delegation possibility; and a
non-404 does not claim a delegation problem. The last one matters — a hint that fires on the wrong
status is worse than no hint, because it sends the next person down the same wrong path this incident
did.

95 tests pass; pnpm check 0 errors; pnpm lint clean.

Scope

This is the observability half. The detection and prevention land in bitborg-infra #262: an apply-time
health gate asserting the portal can manage every group it writes, a critical Loki alert on the first
failed registration, and scripts/signup-drill.sh which proves the whole chain against real Kanidm.

Neither unit tests nor the local e2e harness could have caught the original bug — it is a production
permission mismatch, not logic, and there is no Kanidm locally. Worth being explicit about, since
"add a test" is the instinctive answer and here it would have been false comfort.

Sign-up was broken in production for 13 days (2026-07-17..30) and the **only** evidence was: ``` [signup] Kanidm provisioning failed after person create; rolling back: Error: group add -> 404 ``` That names neither which group failed nor the fact that 404 is ambiguous here — which is most of why it went unfound. ## Why 404 was misleading **Kanidm returns 404 for a denied write, not 403** — it will not confirm the existence of an entry the caller may not manage. So the 404 had two very different causes and the message implied the wrong one. The actual cause was the `entry-managed-by` delegation: sign-up moved from `tier_basic` to `tier_participant` (ADR 0029) and gained `tier_trial` (ADR 0036), but that delegation is a manual `kanidm group set-entry-manager` step and was never re-run — so the portal was denied member-write on the only groups it writes. ## The change `groupWriteError()` now produces: ``` group add tier_participant -> 404 (group missing, OR member-write not delegated to this service account — Kanidm returns 404, not 403, for a denied write; check `entry_managed_by` on the group) ``` Applied to both the tier group and the Forgejo access group, which shared the same uninformative message. The access group is worth the same treatment: a person missing from `forgejo_users` gets zero OIDC scopes, so every Forgejo login is refused and no account is ever JIT-created — silent-but-broken in a different way. ## Tests Three regression tests: the group name is present; a 404 explains the delegation possibility; and a **non-404 does not** claim a delegation problem. The last one matters — a hint that fires on the wrong status is worse than no hint, because it sends the next person down the same wrong path this incident did. 95 tests pass; `pnpm check` 0 errors; `pnpm lint` clean. ## Scope This is the observability half. The detection and prevention land in bitborg-infra #262: an apply-time health gate asserting the portal can manage every group it writes, a critical Loki alert on the first failed registration, and `scripts/signup-drill.sh` which proves the whole chain against real Kanidm. Neither unit tests nor the local e2e harness could have caught the original bug — it is a production permission mismatch, not logic, and there is no Kanidm locally. Worth being explicit about, since "add a test" is the instinctive answer and here it would have been false comfort.

supernaut lade till 1 incheckning

2026-07-30 18:16:17 +00:00

fix(signup): name the group and the likely cause when a Kanidm group write fails

ci / ci (pull_request) Successful in 1m11s

Detaljer

8b50ad58fd

Sign-up was broken in production for 13 days (2026-07-17..30) and the only
evidence was:

  [signup] Kanidm provisioning failed after person create; rolling back:
  Error: group add -> 404

That message names neither which group failed nor the fact that 404 is ambiguous
here, which is most of why it went unfound.

Kanidm returns 404 for a DENIED write, not 403 — it will not confirm the
existence of an entry the caller may not manage. So the 404 had two very
different causes and the message implied the wrong one. The actual cause was the
`entry-managed-by` delegation: sign-up moved from tier_basic to tier_participant
(ADR 0029) and gained tier_trial (ADR 0036), but that delegation is a manual
`kanidm group set-entry-manager` step and was never re-run, so the portal was
denied member-write on the only groups it writes.

groupWriteError() now produces:

  group add tier_participant -> 404 (group missing, OR member-write not delegated
  to this service account — Kanidm returns 404, not 403, for a denied write;
  check `entry_managed_by` on the group)

Used for the tier group and the Forgejo access group, both of which had the same
uninformative message.

Three regression tests assert the group name is present, that a 404 explains the
delegation possibility, and that a non-404 does NOT claim a delegation problem —
the last one matters because a misleading hint is worse than none.

Infra-side mitigations land separately in gitborg-infra: a health gate asserting
the portal can manage every group it writes, a critical Loki alert on the first
failed registration, and scripts/signup-drill.sh which proves the whole chain.

supernaut lade till etiketterna

area/web

type

bug

2026-07-30 18:16:17 +00:00

supernaut sammanfogade incheckning 7f0cf6da54 till main

2026-07-30 18:37:00 +00:00

supernaut tog bort grenen fix/signup-group-write-diagnostics

2026-07-30 18:37:00 +00:00

supernaut refererade denna ändringsförfrågan från en incheckning

2026-07-30 18:37:01 +00:00

fix(signup): name the group and the likely cause when a Kanidm group write fails (#112)