@bongos/core 1.19.239 → 1.19.241

package/tests/idp_federation.mjs

@@ -80,16 +80,18 @@ t('buildIdpAuthorizeUrl throws when the IdP is not configured (never silently mi
   });
 });
 
-console.log('\nmembership check-in role (§3 — coarse, never a rank):');
+console.log('\nmembership check-in kind (§3 — coarse, never a rank, never a craft):');
 
-t('membershipRole is builder by default, owner for the configured firstAdmin', () => {
+t('membershipKind is member by default, owner for the configured firstAdmin', () => {
   const prev = process.env.CLOUDBONGOS_FIRST_ADMIN;
   process.env.CLOUDBONGOS_FIRST_ADMIN = 'ownerlogin';
   try {
-    assert.equal(auth.membershipRole({ githubLogin: 'ownerlogin' }), 'owner');
-    assert.equal(auth.membershipRole({ githubLogin: 'OwnerLogin' }), 'owner', 'case-insensitive');
-    assert.equal(auth.membershipRole({ githubLogin: 'someone-else' }), 'builder');
-    assert.equal(auth.membershipRole({}), 'builder');
+    assert.equal(auth.membershipKind({ githubLogin: 'ownerlogin' }), 'owner');
+    assert.equal(auth.membershipKind({ githubLogin: 'OwnerLogin' }), 'owner', 'case-insensitive');
+    // 'member', not 'builder' — the craft name left the coarse membership vocabulary
+    // with task 1003090 (ADR 0177 §"the fifth use").
+    assert.equal(auth.membershipKind({ githubLogin: 'someone-else' }), 'member');
+    assert.equal(auth.membershipKind({}), 'member');
   } finally {
     if (prev === undefined) delete process.env.CLOUDBONGOS_FIRST_ADMIN;
     else process.env.CLOUDBONGOS_FIRST_ADMIN = prev;

package/tests/membership_kind_lockstep.mjs

@@ -0,0 +1,99 @@
+// tests/membership_kind_lockstep.mjs — the expand-phase lockstep triggers, and the
+// Postgres semantic that makes their shape load-bearing (task 1003090, ADR 0177).
+//
+// Both membership renames keep the legacy column alive for one release, kept in step
+// by a BEFORE INSERT OR UPDATE trigger. The INSERT branch has to answer "did the
+// caller write the NEW column, or is this an old release writing the legacy one?" —
+// and there is exactly ONE way to answer it:
+//
+//   POSTGRES MATERIALIZES A COLUMN DEFAULT INTO `NEW` BEFORE ANY BEFORE ROW TRIGGER
+//   FIRES. So if the new column carries a DEFAULT, `NEW.<new> IS NULL` is never true
+//   and the trigger cannot distinguish "explicitly written" from "default filled".
+//
+// That is not theoretical. With a DEFAULT in place, an old-release
+// `INSERT … (client_id, github_id, role) VALUES (…, 'pending')` — inviteToProject's
+// exact statement — took the "new code wrote it" branch and overwrote `role` with the
+// default's mapping, turning a pending INVITE into an active membership. Caught by
+// the grader on task 1003090 and reproduced against a real Postgres:
+//
+//   A old-invite-pending | role=builder | membership_kind=member   ← WRONG (before)
+//   A old-invite-pending | role=pending | membership_kind=pending  ← after the fix
+//
+// The fix is the absence of a DEFAULT while the legacy column is still written, so
+// NULL means exactly "not written". The DEFAULT (and NOT NULL) belong to step 2,
+// when the legacy column is dropped. This file pins that invariant statically,
+// because the trigger only misbehaves against a live Postgres — which CI has none of.
+//
+// Run:  node --test tests/membership_kind_lockstep.mjs
+import assert from 'node:assert/strict';
+import { test } from 'node:test';
+import fs from 'node:fs';
+import path from 'node:path';
+import { fileURLToPath } from 'node:url';
+
+const ROOT = path.resolve(path.dirname(fileURLToPath(import.meta.url)), '..');
+const read = (rel) => fs.readFileSync(path.join(ROOT, rel), 'utf8');
+
+// core_220 (goal membership) carries the SAME defect and is fixed under task
+// 1003093 — filed, not forgotten. It is deliberately absent from this list rather
+// than silently passing: a class guard that quietly excludes a known-broken member
+// of the class is worse than no guard.
+const EXPAND_MIGRATIONS = [
+  {
+    rel: 'modules/platform-identity/migrations/platform_identity_010_membership_kind.sql',
+    table: 'platform_identity_project_memberships',
+    legacy: 'role',
+  },
+];
+
+for (const m of EXPAND_MIGRATIONS) {
+  test(`${path.basename(m.rel)}: the new column has NO default while ${m.legacy} is still written`, () => {
+    const sql = read(m.rel);
+    assert.ok(/ADD COLUMN IF NOT EXISTS membership_kind text/.test(sql), 'the expand step adds the column');
+    assert.ok(!/ALTER COLUMN membership_kind SET DEFAULT/.test(sql),
+      'a DEFAULT here is materialized into NEW before the BEFORE trigger runs, so the trigger '
+      + 'could no longer tell an explicit write from a filled default — and an old-release INSERT '
+      + `naming only ${m.legacy} would be silently rewritten (task 1003090)`);
+    assert.ok(!/ALTER COLUMN membership_kind SET NOT NULL/.test(sql),
+      'NOT NULL belongs to step 2, once nothing writes the legacy column (and the forward-safety '
+      + 'linter flags it here for the same reason)');
+  });
+
+  test(`${path.basename(m.rel)}: the trigger's INSERT branch keys off NULL, not off truthiness`, () => {
+    const sql = read(m.rel);
+    const fn = sql.slice(sql.indexOf('RETURNS trigger AS'), sql.indexOf('$$ LANGUAGE plpgsql'));
+    const insertBranch = fn.slice(fn.indexOf("IF TG_OP = 'INSERT'"), fn.indexOf('ELSE', fn.indexOf('END IF')));
+    assert.match(insertBranch, /IF NEW\.membership_kind IS NULL THEN/,
+      'NULL is the only reliable signal that the caller did not write the new column');
+    assert.ok(!/IF NEW\.membership_kind IS NOT NULL THEN/.test(insertBranch),
+      'the inverted form is the task-1003090 bug: it treats a filled default as an explicit write');
+    // The UPDATE branch has OLD to compare against, so it may (and does) use IS DISTINCT FROM.
+    assert.match(fn, /NEW\.membership_kind IS DISTINCT FROM OLD\.membership_kind/,
+      'the UPDATE branch decides direction by which side actually changed');
+    assert.ok(/BEFORE INSERT OR UPDATE/.test(sql), 'a BEFORE trigger, so both columns are written by one statement');
+  });
+}
+
+test('the value mapping is one shared function, not repeated inline', () => {
+  // Route, sender and trigger must agree that 'builder' ⇄ 'member'; three copies of a
+  // ternary is how they would stop agreeing.
+  const pi = read('modules/platform-identity/platform-identity.js');
+  assert.match(pi, /function membershipKindFromLegacy\(/);
+  assert.match(pi, /function legacyRoleFromKind\(/);
+  const sso = read('modules/platform-identity/routes/sso.js');
+  assert.match(sso, /pi\.membershipKindFromLegacy\(role\)/,
+    'the check-in translates the legacy field through the shared mapping');
+  const sql = read('modules/platform-identity/migrations/platform_identity_010_membership_kind.sql');
+  assert.match(sql, /CASE WHEN NEW\.role = 'builder' THEN 'member'/, 'the trigger maps the same pair');
+  assert.match(sql, /CASE WHEN NEW\.membership_kind = 'member' THEN 'builder'/);
+});
+
+test('the sender writes BOTH spellings, computing the kind once (the cross-version window)', () => {
+  const auth = read('src/bongos/auth.js');
+  const body = auth.slice(auth.indexOf('async function reportMembershipCheckIn'), auth.indexOf('async function reportMembershipCheckIn') + 2400);
+  assert.match(body, /membership_kind: kind/, 'the new field goes on the wire');
+  assert.match(body, /role: kind === 'member' \? 'builder' : kind/,
+    'and the legacy field too — an un-upgraded hub would otherwise drop the owner flag');
+  assert.equal((body.match(/membershipKind\(\{ githubLogin \}\)/g) || []).length, 1,
+    'the kind is computed ONCE per check-in, not per field');
+});