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

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

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
25/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
elixir, erlang
Área
databases, distributed-systems

Línea de trabajo

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.

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

Descripción

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.
Lenguaje dominante
Elixir
Estrellas
47
Forks
2
Merge medio
10 d 4 h
PR fusionados (30 d)
1

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 phoenixframework/group

Todos los issues de phoenixframework/group

Issues similares

Más issues de Elixir

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.