fix: resolve merge conflicts and fix Migration Dry-Run / Backend Tests CI

Merged origin/main into this branch:
- .github/workflows/ci.yml: main had already independently added the
  same "zk-tests" job content this branch's diff collided with, which
  left main with that job duplicated verbatim. Resolved by keeping one
  copy of zk-tests and appending this branch's new migration-dry-run
  job after it, as originally authored.
- backend/src/db/timescale.ts: kept this branch's new dryRunMigrations
  and getMigrationStatus functions; main had no competing changes here.

Fixed two bugs the merge/CI run surfaced:
- dryRunMigrations ran every pending migration in its own
  BEGIN/ROLLBACK, so a migration's schema changes never persisted for
  the next one in the same run — any migration depending on an earlier
  one (e.g. 007_commitments_cursor_indexes.sql referencing
  commitment_outcomes from 001_timescale_setup.sql) always failed with
  "relation does not exist", regardless of whether the SQL was
  actually correct. Switched to one outer transaction with a savepoint
  per migration, matching what the existing code comment already
  described.
- The Migration Dry-Run job used plain postgres:16, which doesn't have
  the timescaledb extension 001_timescale_setup.sql requires (unlike
  the real docker-compose stack, which uses
  timescale/timescaledb:latest-pg16). Switched the CI service to the
  same image so the dry-run is actually representative.
- This branch's own rename of 004_horizon_sse_cursors.sql ->
  006_horizon_sse_cursors.sql (deduplicating a numbering collision
  with 004_reputation_snapshots.sql) left a stale hardcoded path in
  sse-indexer.test.ts pointing at the old filename, failing Backend
  Tests. Updated both references.

Verified locally: full backend build, `npm test` (all 3 suites), and
migrate-dry-run.js against a real timescale/timescaledb:latest-pg16
container — all 10 migrations now validate successfully.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

Author: amankoli09

.github/workflows/ci.yml

@@ -108,15 +108,18 @@ jobs:
     runs-on: ubuntu-latest
     env:
       # Custom runner reads TIMESCALEDB_* env vars; point them at the ephemeral
-      # postgres:16 service container spun up for this job.
+      # timescaledb service container spun up for this job.
       TIMESCALEDB_HOST: localhost
       TIMESCALEDB_PORT: 5432
       TIMESCALEDB_DATABASE: pactum_migration_test
       TIMESCALEDB_USER: postgres
       TIMESCALEDB_PASSWORD: postgres
     services:
       postgres:
-        image: postgres:16
+        # Same image docker-compose.yml uses for the real service, so
+        # CREATE EXTENSION timescaledb (001_timescale_setup.sql) succeeds here
+        # instead of only in the full docker-compose e2e stack.
+        image: timescale/timescaledb:latest-pg16
         env:
           POSTGRES_PASSWORD: postgres
           POSTGRES_DB: pactum_migration_test
@@ -158,14 +161,8 @@ jobs:
         working-directory: backend
         run: npm run build
 
-      - name: Run migration dry-run against ephemeral PostgreSQL
+      - name: Run migration dry-run against ephemeral TimescaleDB
         working-directory: backend
-        # Note: TimescaleDB-specific DDL (CREATE EXTENSION timescaledb,
-        # create_hypertable, time_bucket) requires the timescaledb extension
-        # which is not available in plain postgres:16. The dry-run validates
-        # checksum integrity and sequential ordering; TimescaleDB-specific
-        # syntax is exercised in the full integration stack (docker compose).
-        # Any migration that fails basic PostgreSQL parsing will still fail here.
         run: node dist/db/migrate-dry-run.js
 
 

backend/src/db/migrations/007_commitments_cursor_indexes.sql

@@ -1,4 +1,4 @@
--- Migration: 005_commitments_cursor_indexes.sql
+-- Migration: 007_commitments_cursor_indexes.sql
 -- Add template column and composite indexes for high-performance cursor-based pagination and filtering
 
 ALTER TABLE commitment_outcomes ADD COLUMN IF NOT EXISTS template VARCHAR(50);

backend/src/db/timescale.ts

@@ -177,36 +177,48 @@ export const dryRunMigrations = async (
       ]),
     );
 
-    for (const file of migrationFiles) {
-      const filePath = path.join(migrationsDir, file);
-      const sql = fs.readFileSync(filePath, 'utf8');
-      const checksum = calculateMigrationChecksum(sql);
-
-      if (appliedMap.has(file)) {
-        const recordedChecksum = appliedMap.get(file);
-        if (recordedChecksum !== checksum) {
-          const msg = `Immutable migration '${file}' has been altered! Recorded: ${recordedChecksum}, Current: ${checksum}`;
-          logger.error(`[dry-run] TAMPERED: ${msg}`);
-          report.push({ file, status: 'tampered', message: msg });
+    // Pending migrations are applied inside one outer transaction, each under its
+    // own savepoint, so a migration sees the cumulative schema left by the pending
+    // migrations before it — exactly as a real sequential apply would. Rolling back
+    // the outer transaction at the end (rather than each migration individually)
+    // means nothing is ever persisted, while dependencies between migrations (e.g.
+    // an index migration referencing a table an earlier migration creates) still
+    // validate correctly instead of spuriously failing with "relation does not
+    // exist".
+    await client.query('BEGIN');
+    try {
+      for (const file of migrationFiles) {
+        const filePath = path.join(migrationsDir, file);
+        const sql = fs.readFileSync(filePath, 'utf8');
+        const checksum = calculateMigrationChecksum(sql);
+
+        if (appliedMap.has(file)) {
+          const recordedChecksum = appliedMap.get(file);
+          if (recordedChecksum !== checksum) {
+            const msg = `Immutable migration '${file}' has been altered! Recorded: ${recordedChecksum}, Current: ${checksum}`;
+            logger.error(`[dry-run] TAMPERED: ${msg}`);
+            report.push({ file, status: 'tampered', message: msg });
+          } else {
+            logger.info(`[dry-run] OK (applied): ${file}`);
+            report.push({ file, status: 'applied' });
+          }
         } else {
-          logger.info(`[dry-run] OK (applied): ${file}`);
-          report.push({ file, status: 'applied' });
-        }
-      } else {
-        // Validate the SQL parses cleanly using a savepoint that we always roll back.
-        await client.query('BEGIN');
-        try {
-          await client.query(sql);
-          logger.info(`[dry-run] OK (pending, syntax valid): ${file}`);
-          report.push({ file, status: 'pending' });
-        } catch (err) {
-          const msg = err instanceof Error ? err.message : String(err);
-          logger.error(`[dry-run] SYNTAX ERROR in ${file}: ${msg}`);
-          report.push({ file, status: 'error', message: msg });
-        } finally {
-          await client.query('ROLLBACK');
+          await client.query('SAVEPOINT dry_run_migration');
+          try {
+            await client.query(sql);
+            await client.query('RELEASE SAVEPOINT dry_run_migration');
+            logger.info(`[dry-run] OK (pending, syntax valid): ${file}`);
+            report.push({ file, status: 'pending' });
+          } catch (err) {
+            await client.query('ROLLBACK TO SAVEPOINT dry_run_migration');
+            const msg = err instanceof Error ? err.message : String(err);
+            logger.error(`[dry-run] SYNTAX ERROR in ${file}: ${msg}`);
+            report.push({ file, status: 'error', message: msg });
+          }
         }
       }
+    } finally {
+      await client.query('ROLLBACK');
     }
 
     return report;

backend/src/indexer/sse-indexer.test.ts

@@ -397,7 +397,7 @@ test(
     try {
       await pool.query(`CREATE SCHEMA "${schema}"`);
       const migration = await readFile(
-        path.join(process.cwd(), 'src/db/migrations/004_horizon_sse_cursors.sql'),
+        path.join(process.cwd(), 'src/db/migrations/006_horizon_sse_cursors.sql'),
         'utf8',
       );
       // Run migration on a dedicated client with search_path locked so the
@@ -444,7 +444,7 @@ test(
     try {
       await pool.query(`CREATE SCHEMA "${schema}"`);
       const migration = await readFile(
-        path.join(process.cwd(), 'src/db/migrations/004_horizon_sse_cursors.sql'),
+        path.join(process.cwd(), 'src/db/migrations/006_horizon_sse_cursors.sql'),
         'utf8',
       );
       // Run migration on a dedicated client with search_path locked so the