Skip to main content

API e2e CI workflow (D14)

Current state​

The multi-instance e2e suite at apps/api/e2e/multi-instance/ runs on-demand locally against the dev Upstash database. There is no .github/workflows/api-e2e.yml. Engineers run the suite when changing code that touches cluster-coordination primitives; CI does not run it per PR.

The deferred alternative​

A GitHub Actions workflow that:

  • Provisions an isolated Upstash test database (or uses a dedicated CI-tier Upstash)
  • Spins up the API in multi-instance configuration via Docker
  • Runs the full multi-instance e2e suite per PR
  • Reports per-test results, including the migration boot coordination cluster scenarios

Why deferred​

  • The suite exists and is runnable. The deferral is about continuous validation, not the test infrastructure.
  • Multi-instance contract changes are infrequent; the cost of a CI workflow is paid on every PR even when the change has nothing to do with cluster coordination.
  • The observability contract (observability-contract.spec.ts) and the unit-test coverage on the semantic Redis services catch most regressions at PR time.

What the deferred CI would buy​

  • Confidence that a PR touching cluster-coordination code does not regress migration boot, Socket.IO fanout, ancestry-invalidate broadcast, etc.
  • Earlier signal than staging — multi-instance correctness bugs caught in staging are recoverable but disruptive.

What the deferred CI would cost​

  • A dedicated Upstash test database (~$10/mo, plus credential management)
  • CI minutes per PR
  • The teaching tax of explaining failures to engineers whose PR doesn't intentionally touch the multi-instance surface

Revisit trigger​

When continuous PR validation for multi-instance correctness is prioritized — typically because a multi-instance regression slipped to staging or production and the team wants earlier signal.