Files

Josep Piguillem a32c937765 fix(api): a read-side failure waits for its event instead of losing it

The Redis consumer used to leave a failed event pending and go on to the
next ones, retrying it only at the next start. With Mongo down for a
while, a later change of the same ticket was then projected first, and
the version check dropped the earlier one for good (a status change
could vanish from the read model), besides the read side lagging until
a restart.

Now a failed event is retried in place, waiting longer each time (up to
30 s), and the next one waits for it. Failures of the infrastructure
(Mongo, Redis, the network: isTransientError) wait as long as it takes,
so the read side catches up by itself; an event that keeps failing on
its own goes, after 5 attempts, to <stream>:dead with its error, so it
does not hold up the rest.

GET /api/health reports the way from write to read (events waiting in
the outbox, pending to be projected, set aside) and says `degraded`,
still with 200, when something is stuck.

Tried for real: with Mongo stopped, two status changes went in; the
first failed to project with ECONNREFUSED, and once Mongo was back the
ticket's history had both steps, in order, without restarting the API.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

2026-10-16 22:24:19 +02:00

src

fix(api): a read-side failure waits for its event instead of losing it

2026-10-16 22:24:19 +02:00

eslint.config.mjs

first commit

2026-10-03 13:40:26 +02:00

jest.config.cts

first commit

2026-10-03 13:40:26 +02:00

project.json

feat: public projects, project deletion and sagas

2026-10-07 07:04:20 +02:00

README.md

fix(api): a read-side failure waits for its event instead of losing it

2026-10-16 22:24:19 +02:00

tsconfig.json

first commit

2026-10-03 13:40:26 +02:00

tsconfig.lib.json

first commit

2026-10-03 13:40:26 +02:00

tsconfig.spec.json

first commit

2026-10-03 13:40:26 +02:00

README.md

api-shared-infrastructure

Event store en PostgreSQL y el camino de los eventos hasta la lectura.

Import: @task-stream/api/shared/infrastructure
Capa: infrastructure · Tags: scope:api-shared, type:infrastructure

Contenido

PostgresEventStore (tabla events, UNIQUE(stream_id, position) → ConcurrencyError).
EventSerializer / EventDeserializer y EventStorePublisher (sustituye al publisher del EventBus: commit() persiste).
EventStoreRelay: copia los eventos nuevos al Redis Stream (FOR UPDATE SKIP LOCKED).
EventsBridge: consume el stream y entrega cada evento a sus @EventsHandler, en orden y esperando (ACK al final); después ejecuta los @Saga() (el EventBus en memoria nunca ve los eventos guardados) y sus comandos, uno a uno.
EventStreamConsumer: reintenta en su sitio el evento que falla (el siguiente espera); los fallos de infraestructura (isTransientError) sin límite, los del propio evento 5 veces y luego a <stream>:dead.
EventPipelineStatus: bandeja de salida, pendientes y apartados, para GET /api/health.
Conexiones Redis (REDIS_CLIENT, GRAPHQL_PUB_SUB) y SharedInfrastructureModule.forRootAsync.

Flujo completo: Arquitectura.

Comandos

npx nx lint api-shared-infrastructure
npx nx test api-shared-infrastructure    # Jest

Reglas de dependencia entre capas: Arquitectura.