Production worker logs (every ~10 minutes, observed 2026-06-10):
ProcessWaitlist failed for tenant registry-platform: DBD::Pg::st execute failed: ERROR: relation "enrollments" does not exist
WaitlistExpiration failed for tenant registry-platform: DBD::Pg::st execute failed: ERROR: relation "waitlist" does not exist
The tenant-aware sweeps (#240/#261) iterate registry.tenants and connect_schema per slug. A row with slug registry-platform exists whose Postgres schema is missing or incomplete, so every sweep errors for it. The per-tenant try/catch isolates it correctly (other tenants unaffected), but it's error-level log noise on a 10-minute cadence.
Investigate:
- What is the
registry-platform row — a seed/placeholder, or a half-provisioned tenant? If it's not a real tenant, delete the row.
- If rows-without-schemas are a legitimate state, the sweeps should skip non-existent schemas up front (the migrations'
to_regnamespace(quote_ident(slug)) IS NULL guard pattern, demoting to a single warn) instead of erroring per run.
Found while watching the post-#264 deploy.
Production worker logs (every ~10 minutes, observed 2026-06-10):
The tenant-aware sweeps (#240/#261) iterate
registry.tenantsandconnect_schemaper slug. A row with slugregistry-platformexists whose Postgres schema is missing or incomplete, so every sweep errors for it. The per-tenant try/catch isolates it correctly (other tenants unaffected), but it's error-level log noise on a 10-minute cadence.Investigate:
registry-platformrow — a seed/placeholder, or a half-provisioned tenant? If it's not a real tenant, delete the row.to_regnamespace(quote_ident(slug)) IS NULLguard pattern, demoting to a single warn) instead of erroring per run.Found while watching the post-#264 deploy.