@everystack/server 0.4.29 → 0.4.31

package/src/owner-enactment.ts

@@ -28,6 +28,8 @@
  * memberships, no grants, and no review.
  */
 
+import { generateReaderGrantSQL } from './role-chain';
+
 /** PostgreSQL 16 — the first version with `GRANT ... WITH INHERIT FALSE, SET TRUE` and role `SET` membership. */
 export const MIN_SERVER_VERSION_NUM = 160000;
 
@@ -88,8 +90,34 @@ export interface GranterCapabilityRow {
   canGrantCreate: boolean;
 }
 
+/** Which connection runs a unit's statements. */
+export type EnactmentConnection = 'operator' | 'master';
+
+/**
+ * ONE independently-failable piece of the plan: everything one SUBJECT needs on one connection.
+ *
+ * The subject is a declared owner (ENACT) or one of the reader's grant kinds — never the whole run.
+ * That grain is the point: the subjects are independent of each other and every statement is
+ * idempotent, so a failure on one must never take the others down. Applying the run as one batch
+ * did exactly that — a single unroutable owner rolled back a co-batched, perfectly grantable owner,
+ * which then never converged on any later re-run because the same batch failed the same way.
+ */
+export interface EnactmentUnit {
+  /** What this converges, named the way a refusal names it: `owner 'report_owner' in schema 'api'`. */
+  subject: string;
+  connection: EnactmentConnection;
+  /** Applied together (ENACT: one transaction). Never interleaved with another subject's. */
+  statements: string[];
+}
+
 /** The routed enactment: statements the operator runs, statements the master must run, and refusals. */
 export interface EnactmentPlan {
+  /**
+   * The independently-failable units, in order. This is the plan the applier runs; `asOperator` and
+   * `asMaster` are the flattened view of the same statements, kept for reporting and for callers
+   * that only need "what will run where".
+   */
+  units: EnactmentUnit[];
   /** Runnable on the operator's own connection. */
   asOperator: string[];
   /** Must run on the master connection (the operator lacks the grant right). */
@@ -98,6 +126,48 @@ export interface EnactmentPlan {
   refusals: string[];
 }
 
+/**
+ * Accumulate units and keep the flattened per-connection views in step. A subject that needs
+ * statements on BOTH connections gets one unit per connection — they cannot share a transaction.
+ */
+interface PlanBuilder {
+  plan: EnactmentPlan;
+  byKey: Map<string, EnactmentUnit>;
+}
+
+function newPlan(): PlanBuilder {
+  return { plan: { units: [], asOperator: [], asMaster: [], refusals: [] }, byKey: new Map() };
+}
+
+function addUnit(b: PlanBuilder, subject: string, connection: EnactmentConnection, statements: string[]): void {
+  const key = `${subject} ${connection}`;
+  let unit = b.byKey.get(key);
+  if (!unit) {
+    unit = { subject, connection, statements: [] };
+    b.byKey.set(key, unit);
+    b.plan.units.push(unit);
+  }
+  unit.statements.push(...statements);
+  (connection === 'operator' ? b.plan.asOperator : b.plan.asMaster).push(...statements);
+}
+
+/**
+ * The refusal a unit that FAILED on the server becomes.
+ *
+ * Every other refusal here is pre-flight — the probe said no connection can do it, so nothing ran.
+ * This one is the residue: a capability probe can be honest and the statement still fail (a
+ * membership cycle the server rejects, a concurrent REVOKE between probe and apply). It is reported
+ * against the ONE subject it belongs to, carries the same runnable fix SQL as its pre-flight
+ * siblings, and says plainly that nothing else in the run was rolled back with it.
+ */
+export function unitRefusal(unit: EnactmentUnit, message: string): string {
+  const fix = unit.statements.map((s) => `${s};`).join('  ');
+  return (
+    `cannot converge ${unit.subject}: ${String(message).trim()} — refused alone; ` +
+    `every other subject in this run stands. Run as a role that can:  ${fix}`
+  );
+}
+
 const IDENT = /^[a-z_][a-z0-9_]*$/;
 function assertIdent(name: string, what: string): void {
   if (!IDENT.test(name)) throw new Error(`Invalid ${what}: ${JSON.stringify(name)} — must match ${IDENT}`);
@@ -135,10 +205,21 @@ ORDER BY d.owner_name, d.schema_name
 
 /**
  * The connection-DEPENDENT probe: run on a connection to learn what CURRENT_USER can grant.
- * Can it `GRANT <owner> TO <operator>` — it holds ADMIN OPTION on the owner (pg_auth_members), or
- * is a superuser (RDS: a member of rds_superuser). Can it `GRANT CREATE ON SCHEMA <schema>` — it
- * owns the schema, holds CREATE WITH GRANT OPTION, or is a superuser. Run on the operator's
- * connection and, when present, on the master's; the router merges the two.
+ * Can it `GRANT <owner> TO <operator>` — it holds ADMIN OPTION on the owner, directly or through a
+ * group. Can it `GRANT CREATE ON SCHEMA <schema>` — it owns the schema or holds CREATE WITH GRANT
+ * OPTION. A REAL superuser can do both unconditionally. Run on the operator's connection and, when
+ * present, on the master's; the router merges the two.
+ *
+ * MEMBERSHIP IN `rds_superuser` IS NOT SUPERUSER, and this probe no longer pretends it is. RDS's
+ * master is `NOSUPERUSER CREATEROLE` and a member of the `rds_superuser` group; treating that
+ * membership as `rolsuper` reported `can_grant_membership: true` for a role the master demonstrably
+ * cannot grant — a DBA-created role it holds no ADMIN OPTION on — so `planOwnerEnactment` routed the
+ * GRANT to the master instead of emitting its precise refusal, and the statement failed mid-batch
+ * (live-confirmed on PostgreSQL 16.13). Whatever `rds_superuser` membership REALLY confers is
+ * already visible to the honest reads below: `pg_has_role(..., 'MEMBER WITH ADMIN OPTION')` follows
+ * indirect admin through a group, and `has_schema_privilege` follows inherited ACLs. The shortcut
+ * added nothing but false positives. The module's contract — the master's capability is PROBED,
+ * never assumed — is the same rule `adopteeProbeSql` (owner-adoption.ts) keeps with `rolsuper` alone.
  */
 export function granterCapabilitySql(owners: DeclaredOwner[]): string {
   const pairs = owners.map((o) => {
@@ -149,21 +230,15 @@ export function granterCapabilitySql(owners: DeclaredOwner[]): string {
   return `
 WITH declared(owner_name, schema_name) AS (VALUES ${pairs.join(', ')}),
 me AS (
-  SELECT b.oid, (b.rolsuper OR EXISTS (
-    SELECT 1 FROM pg_auth_members m JOIN pg_roles g ON g.oid = m.roleid
-    WHERE m.member = b.oid AND g.rolname = 'rds_superuser'
-  )) AS is_super
+  SELECT b.oid, b.rolsuper AS is_super
   FROM pg_roles b WHERE b.rolname = CURRENT_USER
 )
 SELECT
   d.owner_name AS owner,
   d.schema_name AS schema,
-  (me.is_super OR EXISTS (
-    SELECT 1 FROM pg_auth_members m
-    WHERE m.roleid = r.oid AND m.member = me.oid AND m.admin_option
-  )) AS can_grant_membership,
-  (me.is_super OR n.nspowner = me.oid
-     OR has_schema_privilege(me.oid, n.oid, 'CREATE WITH GRANT OPTION')) AS can_grant_create
+  COALESCE(me.is_super OR pg_has_role(me.oid, r.oid, 'MEMBER WITH ADMIN OPTION'), false) AS can_grant_membership,
+  COALESCE(me.is_super OR n.nspowner = me.oid
+     OR has_schema_privilege(me.oid, n.oid, 'CREATE WITH GRANT OPTION'), false) AS can_grant_create
 FROM declared d
 CROSS JOIN me
 LEFT JOIN pg_roles r ON r.rolname = d.owner_name
@@ -172,7 +247,7 @@ ORDER BY d.owner_name, d.schema_name
 `.trim();
 }
 
-const keyOf = (owner: string, schema: string) => `${owner}${schema}`;
+const keyOf = (owner: string, schema: string) => `${owner}\u0000${schema}`;
 
 /**
  * Route the two grants each (owner, schema) may need onto the connection that can run them.
@@ -181,6 +256,10 @@ const keyOf = (owner: string, schema: string) => `${owner}${schema}`;
  * connection is available — then anything the operator cannot do is a refusal, never an
  * unverified attempt on a connection that may not exist. Fable's rule: precise pre-flight
  * refusal beats a mid-batch failure, and the master's capability is PROBED, never assumed.
+ *
+ * Each declared owner is its own UNIT (per connection), so one owner nobody can grant — refused
+ * here, before anything runs — leaves every other owner in the same run free to converge, and a
+ * failure that still reaches the server is charged to the owner that caused it.
  */
 export function planOwnerEnactment(
   operator: string,
@@ -190,9 +269,11 @@ export function planOwnerEnactment(
 ): EnactmentPlan {
   const opCap = new Map(operatorCaps.map((c) => [keyOf(c.owner, c.schema), c]));
   const mCap = masterCaps ? new Map(masterCaps.map((c) => [keyOf(c.owner, c.schema), c])) : null;
-  const plan: EnactmentPlan = { asOperator: [], asMaster: [], refusals: [] };
+  const b = newPlan();
+  const plan = b.plan;
 
   for (const f of facts) {
+    const subject = `owner '${f.owner}' in schema '${f.schema}'`;
     if (!f.roleExists) {
       plan.refusals.push(
         `owner role '${f.owner}' does not exist — provision never invents a security principal. ` +
@@ -206,8 +287,8 @@ export function planOwnerEnactment(
     // 1. Membership: the operator must be able to SET ROLE the owner.
     if (!f.canSetRole) {
       const stmt = `GRANT ${f.owner} TO ${operator} WITH INHERIT FALSE, SET TRUE`;
-      if (op?.canGrantMembership) plan.asOperator.push(stmt);
-      else if (master?.canGrantMembership) plan.asMaster.push(stmt);
+      if (op?.canGrantMembership) addUnit(b, subject, 'operator', [stmt]);
+      else if (master?.canGrantMembership) addUnit(b, subject, 'master', [stmt]);
       else plan.refusals.push(
         `cannot GRANT ${f.owner} TO ${operator}: neither the operator nor the master holds ADMIN OPTION on '${f.owner}'. ` +
         `Run as a role that does:  ${stmt};`,
@@ -217,8 +298,8 @@ export function planOwnerEnactment(
     // 2. Create: the owner must be able to CREATE in the schema the object lives in.
     if (f.schemaExists && !f.ownerCanCreate) {
       const stmt = `GRANT CREATE ON SCHEMA ${f.schema} TO ${f.owner}`;
-      if (op?.canGrantCreate) plan.asOperator.push(stmt);
-      else if (master?.canGrantCreate) plan.asMaster.push(stmt);
+      if (op?.canGrantCreate) addUnit(b, subject, 'operator', [stmt]);
+      else if (master?.canGrantCreate) addUnit(b, subject, 'master', [stmt]);
       else plan.refusals.push(
         `cannot GRANT CREATE ON SCHEMA ${f.schema} TO ${f.owner}: neither connection owns the schema or holds CREATE WITH GRANT OPTION. ` +
         `Run as the schema owner:  ${stmt};`,
@@ -229,3 +310,257 @@ export function planOwnerEnactment(
   }
   return plan;
 }
+
+// --- the reader's read grants — the THIRD grant kind, same probe → route → refuse machinery -----
+//
+// db:provision creates the SELECT-only login (`reader`, see generateReaderRoleSQL) that db:query
+// connects as. A login with no grants reads nothing, so provision must also make the grants — and
+// those grants are exactly as unroutable as ENACT's two: on a brownfield database the app's schema
+// may be owned by someone the least-privilege operator cannot grant on behalf of, and the grant has
+// to run on the master instead. Same shape as above: connection-INDEPENDENT facts (what is
+// missing), connection-DEPENDENT capability (what THIS connection may grant), then a router.
+
+/**
+ * What is still missing for the reader, per (schema, creator). Connection-independent — read once
+ * on either connection. `creator` is null-shaped as the empty string for a schema with no declared
+ * creating role; then only the schema-wide facts matter.
+ */
+export interface ReaderGrantFactRow {
+  schema: string;
+  creator: string;
+  /** The schema exists. Grants are written on what is there; an absent schema is skipped. */
+  schemaExists: boolean;
+  /** The creating role exists. An absent one gets no ALTER DEFAULT PRIVILEGES — never invented. */
+  creatorExists: boolean;
+  /** The reader lacks USAGE on the schema. */
+  usageMissing: boolean;
+  /** At least one table/view/matview/sequence in the schema is not SELECT-able by the reader. */
+  selectMissing: boolean;
+  /**
+   * The default privileges for (creator, schema) do not yet grant the reader SELECT on TABLES.
+   *
+   * TABLES and SEQUENCES are tracked separately, and deliberately so: PostgreSQL stores them as
+   * distinct `pg_default_acl` rows (`defaclobjtype` 'r' vs 'S'), and either can exist without the
+   * other — an operator who ran `ALTER DEFAULT PRIVILEGES ... ON TABLES` by hand, or a grant run
+   * that got half way. One combined flag reports "converged" as soon as EITHER row is present, so
+   * the missing one is never emitted again on any re-provision: silently, permanently unconverged,
+   * exactly where a probe-plan-converge design is supposed to self-heal.
+   */
+  tablesDefaultsMissing: boolean;
+  /** The same, for SEQUENCES. See `tablesDefaultsMissing` for why the two are not one flag. */
+  sequencesDefaultsMissing: boolean;
+}
+
+/** What ONE connection may grant for the reader, per (schema, creator) — read with CURRENT_USER. */
+export interface ReaderGranterCapabilityRow {
+  schema: string;
+  creator: string;
+  /** Can `GRANT USAGE ON SCHEMA` — owns the schema, holds USAGE WITH GRANT OPTION, or is a superuser. */
+  canGrantUsage: boolean;
+  /** Can `GRANT SELECT` on EVERY relation in the schema — holds SELECT WITH GRANT OPTION on each. */
+  canGrantSelect: boolean;
+  /** Can `ALTER DEFAULT PRIVILEGES FOR ROLE <creator>` — is a member of it, or a superuser. */
+  canSetDefaults: boolean;
+}
+
+/** `('app', 'migrator')` rows, or `('app', NULL)` for a schema with no declared creating role. */
+function readerPairs(schemas: string[], creators: string[]): string {
+  schemas.forEach((s) => assertIdent(s, 'schema'));
+  creators.forEach((c) => assertIdent(c, 'creator'));
+  const rows: string[] = [];
+  for (const schema of schemas) {
+    if (!creators.length) rows.push(`('${schema}', NULL)`);
+    else for (const creator of creators) rows.push(`('${schema}', '${creator}')`);
+  }
+  return rows.join(', ');
+}
+
+/**
+ * The connection-independent probe: for each (schema, creator), what does the reader still lack?
+ *
+ * Every "missing" fact is read from the catalog rather than assumed, so a re-provision on a
+ * converged database emits NOTHING. That matters more here than for the owner grants: `GRANT ... ON
+ * ALL TABLES` takes an ACCESS EXCLUSIVE lock on every table it touches, so re-issuing it on each
+ * deploy would be a lock storm on a busy database for no change at all.
+ *
+ * `has_table_privilege` is used for sequences too (it accepts them); the relation list is fenced
+ * behind `OFFSET 0` because the planner may otherwise evaluate the privilege call before the
+ * relkind filter and error on a TOAST relation.
+ *
+ * THE DEFAULT PRIVILEGES ARE TWO FACTS, NOT ONE. `pg_default_acl` holds a separate row per object
+ * kind, so `defaclobjtype = 'r'` (TABLES) and `= 'S'` (SEQUENCES) get one `EXISTS` each. Asking
+ * `defaclobjtype IN ('r','S')` would report BOTH converged the moment EITHER row exists — and the
+ * missing statement would then never be planned again, because the plan is driven entirely by
+ * these facts. That is reachable with no failure at all: a brownfield operator who already ran
+ * `ALTER DEFAULT PRIVILEGES ... ON TABLES` by hand, or a prior grant run that got half way.
+ * "Converged" therefore has two independent answers per (schema, creator), and `planReaderGrants`
+ * gates the two statements separately.
+ */
+export function readerGrantFactsSql(reader: string, schemas: string[], creators: string[]): string {
+  assertIdent(reader, 'reader');
+  const pairs = readerPairs(schemas, creators);
+  return `
+WITH declared(schema_name, creator) AS (VALUES ${pairs}),
+rdr AS (SELECT oid FROM pg_roles WHERE rolname = '${reader}')
+SELECT
+  d.schema_name AS schema,
+  COALESCE(d.creator, '') AS creator,
+  (n.oid IS NOT NULL) AS schema_exists,
+  (c.oid IS NOT NULL) AS creator_exists,
+  CASE WHEN n.oid IS NULL OR rdr.oid IS NULL THEN true
+       ELSE NOT has_schema_privilege(rdr.oid, n.oid, 'USAGE') END AS usage_missing,
+  CASE WHEN n.oid IS NULL OR rdr.oid IS NULL THEN true
+       ELSE EXISTS (
+         SELECT 1 FROM (
+           SELECT k.oid FROM pg_class k
+           WHERE k.relnamespace = n.oid AND k.relkind IN ('r','p','v','m','f','S')
+           OFFSET 0
+         ) rel
+         WHERE NOT has_table_privilege(rdr.oid, rel.oid, 'SELECT')
+       ) END AS select_missing,
+  CASE WHEN n.oid IS NULL OR c.oid IS NULL OR rdr.oid IS NULL THEN true
+       ELSE NOT EXISTS (
+         SELECT 1 FROM pg_default_acl da, aclexplode(da.defaclacl) a
+         WHERE da.defaclrole = c.oid AND da.defaclnamespace = n.oid
+           AND da.defaclobjtype = 'r' AND a.grantee = rdr.oid AND a.privilege_type = 'SELECT'
+       ) END AS tables_defaults_missing,
+  CASE WHEN n.oid IS NULL OR c.oid IS NULL OR rdr.oid IS NULL THEN true
+       ELSE NOT EXISTS (
+         SELECT 1 FROM pg_default_acl da, aclexplode(da.defaclacl) a
+         WHERE da.defaclrole = c.oid AND da.defaclnamespace = n.oid
+           AND da.defaclobjtype = 'S' AND a.grantee = rdr.oid AND a.privilege_type = 'SELECT'
+       ) END AS sequences_defaults_missing
+FROM declared d
+CROSS JOIN rdr
+LEFT JOIN pg_namespace n ON n.nspname = d.schema_name
+LEFT JOIN pg_roles c ON c.rolname = d.creator
+ORDER BY d.schema_name, d.creator
+`.trim();
+}
+
+/**
+ * The connection-DEPENDENT probe: what may CURRENT_USER grant for the reader?
+ *
+ * `GRANT ... ON ALL TABLES` run by a role that lacks the grant option on some relations does NOT
+ * error — it emits a warning and silently skips them. So capability is probed per schema BEFORE
+ * anything runs, and a schema the connection cannot fully cover is routed to the master or refused.
+ * A partial grant that looks like success is the failure mode this probe exists to prevent.
+ *
+ * `rolsuper` alone means superuser here — membership in `rds_superuser` does NOT, for exactly the
+ * reason spelled out on `granterCapabilitySql`. On RDS that shortcut claimed the master could grant
+ * SELECT on a table a DBA owns and it cannot; the honest reads below (which follow inherited ACLs,
+ * including anything `rds_superuser` membership really carries) route it to a refusal instead.
+ */
+export function readerGrantCapabilitySql(schemas: string[], creators: string[]): string {
+  const pairs = readerPairs(schemas, creators);
+  return `
+WITH declared(schema_name, creator) AS (VALUES ${pairs}),
+me AS (
+  SELECT b.oid, b.rolsuper AS is_super
+  FROM pg_roles b WHERE b.rolname = CURRENT_USER
+)
+SELECT
+  d.schema_name AS schema,
+  COALESCE(d.creator, '') AS creator,
+  (me.is_super OR (n.oid IS NOT NULL AND (n.nspowner = me.oid
+     OR has_schema_privilege(me.oid, n.oid, 'USAGE WITH GRANT OPTION')))) AS can_grant_usage,
+  (me.is_super OR (n.oid IS NOT NULL AND NOT EXISTS (
+     SELECT 1 FROM (
+       SELECT k.oid FROM pg_class k
+       WHERE k.relnamespace = n.oid AND k.relkind IN ('r','p','v','m','f','S')
+       OFFSET 0
+     ) rel
+     WHERE NOT has_table_privilege(me.oid, rel.oid, 'SELECT WITH GRANT OPTION')
+  ))) AS can_grant_select,
+  (me.is_super OR (c.oid IS NOT NULL AND pg_has_role(me.oid, c.oid, 'USAGE'))) AS can_set_defaults
+FROM declared d
+CROSS JOIN me
+LEFT JOIN pg_namespace n ON n.nspname = d.schema_name
+LEFT JOIN pg_roles c ON c.rolname = d.creator
+ORDER BY d.schema_name, d.creator
+`.trim();
+}
+
+/**
+ * Route the reader's read grants onto the connection that can run each — the third grant kind,
+ * decided the same way as ENACT's two.
+ *
+ * Emits a statement ONLY when its fact says it is missing (idempotence by construction), and only
+ * when some connection can actually make it. Where neither can, the refusal carries the runnable
+ * SQL — the same contract as planOwnerEnactment, so an operator who must run one grant as the
+ * schema owner can copy it verbatim. `masterCaps` is null when there is no master connection: then
+ * anything the operator cannot do is a refusal, never an attempt on a connection that may not exist.
+ *
+ * A schema may appear in several rows (one per creating role); the schema-wide USAGE and SELECT
+ * grants are considered once, on its first row. That is safe because both capabilities are read
+ * from the SCHEMA alone (`readerGrantCapabilitySql`), so every row of a schema carries the same
+ * answer — only `canSetDefaults` varies per creating role.
+ */
+export function planReaderGrants(
+  reader: string,
+  facts: ReaderGrantFactRow[],
+  operatorCaps: ReaderGranterCapabilityRow[],
+  masterCaps: ReaderGranterCapabilityRow[] | null,
+): EnactmentPlan {
+  // keyOf is the generic two-part key; here the pair is (schema, creator), not (owner, schema).
+  const opCap = new Map(operatorCaps.map((c) => [keyOf(c.schema, c.creator), c]));
+  const mCap = masterCaps ? new Map(masterCaps.map((c) => [keyOf(c.schema, c.creator), c])) : null;
+  const b = newPlan();
+  const plan = b.plan;
+  const schemaDone = new Set<string>();
+
+  // Each grant kind is its own unit — the same grain as ENACT's per-owner units, and for the same
+  // reason: a schema whose tables a DBA owns must not cost the reader its grants everywhere ELSE.
+  const route = (
+    subject: string,
+    statements: string[],
+    can: (c: ReaderGranterCapabilityRow) => boolean,
+    op: ReaderGranterCapabilityRow | undefined,
+    master: ReaderGranterCapabilityRow | null,
+    refusal: (fix: string) => string,
+  ): void => {
+    if (op && can(op)) addUnit(b, subject, 'operator', statements);
+    else if (master && can(master)) addUnit(b, subject, 'master', statements);
+    else plan.refusals.push(refusal(statements.map((s) => `${s};`).join('  ')));
+  };
+
+  for (const f of facts) {
+    const op = opCap.get(keyOf(f.schema, f.creator));
+    const master = mCap?.get(keyOf(f.schema, f.creator)) ?? null;
+    if (!f.schemaExists) continue; // grants are written on what exists — see planOwnerEnactment
+
+    const [grants] = generateReaderGrantSQL({ readerRole: reader, schemas: [f.schema], creators: f.creator ? [f.creator] : [] });
+
+    if (!schemaDone.has(f.schema)) {
+      schemaDone.add(f.schema);
+      if (f.usageMissing) {
+        route(`the reader's USAGE on schema '${f.schema}'`, [grants.usage], (c) => c.canGrantUsage, op, master, (fix) =>
+          `cannot GRANT USAGE ON SCHEMA ${f.schema} TO ${reader}: neither connection owns the schema or holds USAGE WITH GRANT OPTION. ` +
+          `Run as the schema owner:  ${fix}`);
+      }
+      if (f.selectMissing) {
+        route(`the reader's SELECT in schema '${f.schema}'`, grants.select, (c) => c.canGrantSelect, op, master, (fix) =>
+          `cannot GRANT SELECT in schema ${f.schema} TO ${reader}: neither connection holds SELECT WITH GRANT OPTION on every relation there. ` +
+          `Run as their owner:  ${fix}`);
+      }
+    }
+
+    // TABLES and SEQUENCES are gated one by one, never as a pair: they are separate catalog rows
+    // and either can already be in place (see ReaderGrantFactRow.tablesDefaultsMissing). Only the
+    // kinds actually missing are emitted, so a converged database still plans nothing.
+    if (f.creator && f.creatorExists) {
+      const [def] = grants.defaults;
+      const missing: string[] = [];
+      if (f.tablesDefaultsMissing) missing.push(def.tables);
+      if (f.sequencesDefaultsMissing) missing.push(def.sequences);
+      if (missing.length) {
+        route(`the reader's default privileges for role '${f.creator}' in schema '${f.schema}'`,
+          missing, (c) => c.canSetDefaults, op, master, (fix) =>
+          `cannot ALTER DEFAULT PRIVILEGES FOR ROLE ${f.creator} IN SCHEMA ${f.schema}: neither connection is a member of '${f.creator}'. ` +
+          `Without it, a table created later by '${f.creator}' is invisible to ${reader} until the next provision. ` +
+          `Run as a member of it:  ${fix}`);
+      }
+    }
+  }
+  return plan;
+}