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

Open
  • Is something wrong?
#32 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
25/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
elixir, erlang
Domain
databases, distributed-systems

Research direction

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.

Written by the indexing model from the issue text.

Description

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.
Dominant language
Elixir
Stars
47
Forks
2
Avg merge
10d 4h
Merged PRs (30d)
1

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from phoenixframework/group

All issues in phoenixframework/group

Similar issues

More Elixir issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.