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

Đang mở
  • Có gì không ổn?
#32 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
25/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
elixir, erlang
Lĩnh vực
databases, distributed-systems

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.
Ngôn ngữ chính
Elixir
Star
47
Fork
2
Merge trung bình
10 ngày 4 giờ
Pull request đã merge (30 ngày)
1

Chuẩn bị môi trường

Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của phoenixframework/group

Tất cả issue của phoenixframework/group

Issue tương tự

Thêm issue về Elixir

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.