vibecarbon 0.1.2 → 0.1.3

package/carbon/docker-compose.yml

@@ -129,9 +129,31 @@ services:
       - -c
       - archive_mode=on
       - -c
-      - archive_command=/usr/local/bin/wal-g wal-push %p
+      # Fault-tolerant wrapper around `wal-g wal-push`. If wal-g fails (S3
+      # outage, bad creds, missing bucket), the wrapper retries with backoff
+      # then logs "WAL_ARCHIVE_FAILED" to stderr and exits 0 so PG can recycle
+      # the segment instead of pinning the entire pg_wal directory. Without
+      # this, a single archive failure pins WAL forever and fills the disk
+      # within days (~20 GiB/day of WAL on an idle Supabase DB given
+      # archive_timeout below, because supabase extensions like pg_cron,
+      # pg_stat_statements, realtime publications all generate background
+      # writes every minute). RCA: prod-1 2026-05-26, 58 GiB of WAL retained
+      # in 3 days because wal-g couldn't reach the configured S3 bucket;
+      # disk filled, db went into Error state, /api/v1/notifications 500'd,
+      # whole stack down. Trade-off: a persistent archive outage leaves a
+      # PITR gap, but the DB stays up — strictly better than the previous
+      # behavior for a SaaS template. Grep `docker logs db` for
+      # WAL_ARCHIVE_FAILED to detect silent backup regressions.
+      - archive_command=/etc/postgresql/wal-archive.sh %p
       - -c
-      - archive_timeout=60
+      # 60s was too aggressive — on an idle Supabase DB, that forces a
+      # 16 MiB segment switch every minute regardless of write volume (PG14+
+      # is supposed to skip empty switches but supabase's bundled extensions
+      # write enough every minute to trip it). 23 GiB/day of WAL baseline.
+      # 900s (15 min) drops baseline to ~1.5 GiB/day with an RPO cap that's
+      # plenty for SaaS workloads. Override via postgresql.conf or compose
+      # if tighter RPO is needed.
+      - archive_timeout=900
       - -c
       # hot_standby=on lets a server in recovery mode (i.e. our standby)
       # accept read-only psql connections. Required so failover's
@@ -167,6 +189,7 @@ services:
       WALG_COMPRESSION_METHOD: lz4
     volumes:
       - db_data:/var/lib/postgresql/data
+      - ./volumes/db/wal-archive.sh:/etc/postgresql/wal-archive.sh:ro,Z
       - ./volumes/db/roles.sql:/docker-entrypoint-initdb.d/init-scripts/98-roles.sql:Z
       - ./volumes/db/jwt.sql:/docker-entrypoint-initdb.d/init-scripts/99-jwt.sql:Z
       - ./volumes/db/realtime.sql:/docker-entrypoint-initdb.d/migrations/99-realtime.sql:Z

package/carbon/functions/main/index.ts

@@ -0,0 +1,17 @@
+// Edge Functions main entrypoint.
+//
+// docker-compose.prod.yml starts the supabase/edge-runtime container with
+// `--main-service /home/deno/functions/main`, which requires this file to
+// exist. Without it the container crash-loops with
+// "could not find an appropriate entrypoint".
+//
+// This stub returns 404 for any path. Add real edge functions by routing in
+// the request handler below, or by mounting per-function directories under
+// functions/<name>/index.ts and updating this dispatcher.
+
+Deno.serve((_req: Request) => {
+  return new Response(
+    JSON.stringify({ error: 'No edge function configured for this path' }),
+    { status: 404, headers: { 'content-type': 'application/json' } }
+  );
+});

package/carbon/vite.config.ts

@@ -68,7 +68,19 @@ export default defineConfig(({ mode }) => {
               return 'vendor-react';
             if (id.includes('node_modules/@supabase/')) return 'vendor-supabase';
             if (id.includes('node_modules/@tanstack/react-query')) return 'vendor-query';
-            if (id.includes('node_modules/recharts')) return 'vendor-charts';
+            // DO NOT split recharts into its own chunk. With rolldown-vite (Vite 8 +
+            // rolldown 1.x), splitting a CJS-React consumer causes rolldown to bundle
+            // a *second* copy of React inside that chunk to satisfy the CJS interop
+            // for `import * as React from 'react'`. The main entry then imports its
+            // React namespace (X.lazy, X.useState) from the recharts chunk while
+            // page chunks still import from vendor-react — two Reacts in one app.
+            // React.lazy elements created by one and rendered by the other resolve
+            // to {} and React throws minified #306 ("Lazy element type must resolve
+            // to a class or function") on first render → ErrorBoundary catches →
+            // white screen. Verified 2026-05-26 against rolldown 1.0.1 by patching
+            // the deployed vendor-react and dumping the failing lazy's payload.
+            // Leave recharts in the default chunk so React stays single-copy.
+            // if (id.includes('node_modules/recharts')) return 'vendor-charts';
             if (id.includes('node_modules/framer-motion')) return 'vendor-motion';
             if (
               id.includes('node_modules/cmdk') ||

package/carbon/volumes/db/wal-archive.sh

@@ -0,0 +1,43 @@
+#!/bin/bash
+# Fault-tolerant archive_command for Postgres + wal-g.
+#
+# Standard archive_command (`wal-g wal-push %p`) blocks WAL recycling until it
+# succeeds. If wal-g fails for any reason (S3 outage, bad credentials, bucket
+# missing, network), pg_wal grows unbounded — combined with archive_timeout
+# this fills the disk in days even on an idle DB.
+#
+# This wrapper:
+#   1. Tries `wal-g wal-push` with $RETRIES attempts and exponential backoff.
+#   2. On final failure, logs loudly to stderr (visible in `docker logs db`)
+#      and exits 0 so PG can recycle the segment. PITR coverage degrades for
+#      the failed segment; the database stays up.
+#
+# Trade-off: a persistent archive outage means a gap in your PITR chain. The
+# alternative — letting WAL fill the disk and taking the DB offline — is worse
+# for any SaaS template. Monitor for the "WAL_ARCHIVE_FAILED" line to detect
+# silent backup regressions.
+#
+# Invoked by postgres as: wal-archive.sh <wal-file-path>
+# %p is passed by Postgres and is the absolute path to the WAL segment.
+
+set -u
+WAL_PATH="${1:?archive_command requires a WAL file path}"
+RETRIES="${WAL_ARCHIVE_RETRIES:-3}"
+SLEEP_BASE="${WAL_ARCHIVE_SLEEP:-2}"
+
+attempt=1
+while [ "$attempt" -le "$RETRIES" ]; do
+    if /usr/local/bin/wal-g wal-push "$WAL_PATH"; then
+        exit 0
+    fi
+    if [ "$attempt" -lt "$RETRIES" ]; then
+        sleep_for=$((SLEEP_BASE ** attempt))
+        sleep "$sleep_for"
+    fi
+    attempt=$((attempt + 1))
+done
+
+# All retries exhausted. Loud, greppable log line so monitoring/alerting can
+# catch this — but exit 0 so PG recycles the segment instead of pinning it.
+echo "WAL_ARCHIVE_FAILED: wal-g wal-push '$WAL_PATH' failed after $RETRIES attempts; allowing PG to recycle (PITR gap for this segment)" >&2
+exit 0

package/carbon/volumes/loki/loki-config.yml

@@ -56,3 +56,11 @@ compactor:
   retention_enabled: true
   retention_delete_delay: 2h
   compaction_interval: 10m
+  # Loki 3.x requires delete_request_store when retention_enabled is true,
+  # otherwise the container fails to start with "CONFIG ERROR: invalid
+  # compactor config: compactor.delete-request-store should be configured
+  # when retention is enabled" and crash-loops. RCA: prod-1 2026-05-26,
+  # loki had been restart-looping since first deploy because of this.
+  # filesystem matches the storage_config above; switch to s3/gcs if the
+  # rest of loki storage moves off filesystem.
+  delete_request_store: filesystem

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "vibecarbon",
-  "version": "0.1.2",
+  "version": "0.1.3",
   "description": "Create and manage production-ready Vibecarbon applications",
   "type": "module",
   "bin": "./src/cli.js",