Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

cluster: a runner that lost its shard lock can still write replies and messages for that shard

Abierto
  • ¿Algo no está bien?
#10,058 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
35/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
postgresql, typescript
Área
databases, distributed-systems

Línea de trabajo

Start with SqlMessageStorage and SqlRunnerStorage in effect/cluster, then read the shard reset and write paths named in the issue: resetShards, saveReply, saveRequest, saveEnvelope, clearReplies and clearAddress. Run the linked repro against the current code to confirm stale writes after lock loss. Done means shard writes from an old owner are rejected after a new owner resets the shard, while client writes without a fence still work.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Base: effect 4.0.6 (effect/cluster, SqlMessageStorage + SqlRunnerStorage on PostgreSQL advisory locks). main has the same code.

What happens. Shard ownership is a session advisory lock. A runner checks it every shardLockRefreshInterval.
Between two checks, the runner can lose the lock (its lock session ended, or it was paused) while another runner
acquires the shard, runs resetShards, and starts the same entities. The old runner does not know yet. Its handlers
finish and call saveReply, saveRequest, saveEnvelope, clearReplies and clearAddress. None of these check
who owns the shard, so the writes succeed.

Results:

  • A persisted request gets two replies, or the old owner's reply wins over the new owner's.
  • A clearReplies or clearAddress from the old owner deletes what the new owner just wrote.
  • With a duplicate primary key, the write is deduplicated with no error, so nobody sees it.

Repro (two runners believe they own one shard):

const cluster = yield* make({ backend: "pg", entities: HoldEntityLayer }) // persisted RPC that waits on a gate
const [stale] = yield* cluster.start(1)
const reply = yield* client("held").Hold(new Request({ id: "fenced" })).pipe(Effect.forkChild)
// handler has started on `stale`
yield* cluster.freeze(stale)              // stale stops refreshing
yield* cluster.dropLockSessions           // pg_terminate_backend on its lock session
const [owner] = yield* cluster.start(1)   // owner acquires the shard and re-runs the request
assert(stale.sharding.hasShardId(shard))  // stale still believes it owns it
openGate(stale)                           // stale's handler finishes first
// 4.0.6: stale's reply is stored and returned to the caller.
// Expected: stale's saveReply fails; only owner's reply is stored.

Expected. Each shard acquisition gets an epoch. Every write on behalf of a shard carries the epoch the writer
acquired with, and storage rejects it in the same transaction if the shard's epoch has moved on. The rejection is a
typed error, logged at Error, and the entity on the stale runner stops.

Proposed fix (implemented on a fork, PR available).

  • SqlMessageStorage migration 0004_shard_epochs adds <prefix>_shards (shard_id, epoch).
  • resetShards raises the epoch of each shard it resets and returns a ShardFence per shard.
  • MessageStorage.CurrentShardFence carries the fence to the write. saveRequest, saveEnvelope, saveReply,
    clearReplies and clearAddress read the shard's epoch with a shared row lock (FOR SHARE, LOCK IN SHARE MODE,
    HOLDLOCK) inside the write's transaction, and fail with ShardFenced if it differs. resetShards takes the
    exclusive lock on the same row, so a stale write either commits before the new owner's reset or fails.
  • Writes by a client (sending to a shard it does not own) carry no fence and are not checked.
  • An entity whose reply is fenced is stopped. Sharding releases a shard whose reset fails.

Runnable repro (real runner processes, fails on 4.0.6 and on main at 837e906): https://github.com/heyimcarlos/effect-cluster-repro, issue 3 in the README table.

Lenguaje dominante
TypeScript
Estrellas
16.7k
Forks
808
Merge medio
10 h 15 min
PR fusionados (30 d)
845

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de Effect-TS/effect

Todos los issues de Effect-TS/effect

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.