Shard 0 can be killed between calls to Data, leading to an inconsistent ets state

Aperta
  • Qualcosa non va?
#32 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
25/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
elixir, erlang
Ambito
databases, distributed-systems

Direzione di ricerca

The two-step update is in the replica_cluster_open handler, where Data.put_remote_cluster_epochs runs before Data.add_cluster_node; the same pattern exists in replica_cluster_close. Start by reading shard 0's handling of those messages and the Data module's ets writes, then check whether a crash between the calls leaves the table inconsistent. Done means the two updates are made atomic or repaired on restart, and a test (or DST seed) that kills shard 0 between the calls no longer leaves c's epochs recorded without c in cluster_nodes.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Hello, human here. This bug report is written by me, and is the result of an analysis with a DST library with agent-human collaboration. I am working on elixir support in eta for deterministic sim testing. I've applied some DST passes to Group, and I believe identified a correctness bug.

Description

Imagine we have shard 0 on node b processing :replica_cluster_open from node c. If we :kill shard 0 after the call to Data.put_remote_cluster_epochs, but before the call to Data.add_cluster_node, then the ets table is left in an inconsistent state w.r.t. the knowledge b has of c's data.

Specifically, b has recorded c's epochs, but has not included c in the cluster_nodes. When shard 0 starts again on b, the observed revision == exact revision for c. However, b's cluster_nodes still omits c, so b does not send to c.

I haven't seen a mechanism that would repair this state, so I believe it persists long term. A rejoin of c would probably resolve it.

The same 2-step Data call appears to exist on :replica_cluster_close as well.

The TLA+ model treats this step as an atomic update to Data, so it is not caught there.

Testing performed on main at 08b5a5.

DST details

Config:

  • The harness is configured to kill shard 0 at arbitrary times during execution. eta allows a process to be killed when it is waiting in a receive (e.g. GenServer.call waiting for a response).
  • No network faults were simulated.
  • Under this config, 2 of 600 seeds showed the failure.

Code:

  • In order to instrument Group for DST with eta, I've had to make changes locally. The changes are focused on allowing Group to run multiple nodes within the same VM. The code is in my fork here.
  • Details about the issue were confirmed on unmodified main outside of DST, but not a full runtime reproduction.
Lingua principale
Elixir
Stelle
47
Fork
2
Merge medio
10g 4h
PR unite (30g)
1

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di phoenixframework/group

Tutte le issue di phoenixframework/group

Issue simili

Altre issue su Elixir

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.