Repository navigation
Troubleshooting
This is Supabase's own Supavisor connection-pooler error signature, seen directly in live
Vercel function logs for print-shop/northline. It means the Supabase project behind
that connection string has been paused (free-tier auto-pause after inactivity) or
deleted — it is not an application bug in this codebase. The app's catalog read path
detects this exact error shape (and the MongoDB driver's equivalent,
MongoServerSelectionError) and renders a graceful "may be asleep" state with a retry
button rather than crashing. A daily GitHub Actions job attempts to wake/revive the real
backend automatically; check the Actions tab for its latest run and outcome. If a project
was actually deleted rather than paused, automated revival can't help — it needs manual
recreation and reseeding.
Check the integrations catalog's
persistence-adapter table for the real per-adapter status, or read
apps/reference-storefront/lib/services.ts's adapter-priority resolution directly — it
checks DATABASE_URL, then MONGODB_URL, then CONVEX_URL (each with a
<DEMO>_-prefixed per-demo override), falling back to the zero-infra SQLite default when
none are set. Today, print-shop and northline resolve to Postgres, broadleaf
resolves to Convex.
No recurring, repo-specific pnpm install or build failures are currently known from CI
history. If you hit one, check the repo's own GitHub Actions CI run for the exact failing
step before assuming it's environmental — this page will get a real entry here the first
time a genuine recurring issue is found and diagnosed.
A live mongosh connection attempt against a configured Atlas cluster can hang for the
full server-selection timeout with no response. This is consistent with the cluster being
paused, deleted, or network-blocked (e.g. Vercel's serverless egress IP ranges not yet
added to the cluster's Network Access allowlist — this exact cause was previously diagnosed
and reverted for adapter-mongodb, per the integrations catalog). adapter-mongodb is not
currently the live backend for any demo, so this doesn't affect production today, but
it's the same underlying failure class as the Supabase pooler error above if you're
standing up your own MongoDB-backed deployment.