Shard 0 can be killed between calls to Data, leading to an inconsistent ets state
まだ誰も着手していません。
評価
- 難易度
- 4/5
- 見積もり時間
- 3〜5日
- 初心者へのやさしさ
- 25/100
- issue の種類
- バグ
- 明瞭さ
- おおむね明確
- 活発さ
- 活発
- 技術スタック
- elixir, erlang
調査の方向性
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.
索引モデルが issue の本文から書いたものです。
説明
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.callwaiting 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.
- 主要言語
- Elixir
- スター
- 47
- フォーク
- 2
- 平均マージ
- 10日 4時間
- マージ済み PR（30日）
- 1
環境構築
このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
phoenixframework/group のほかの issue
-
難易度 5/5 1週間以上 初心者へのやさしさ 12/100
phoenixframework/group#33 ·
phoenixframework/group の issue をすべて見る
似ている issue
-
Bug: Table layout and date column are cut off on mobile screens on the Tournaments -> History pageオープンbug
難易度 2/5 1〜3時間 初心者へのやさしさ 74/100
hexlet-codebattle/codebattle#2375 ·
-
Bug
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
wintermeyer/vutuv#2388 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 74/100
-
Broadcast API docs say to prepend realtime: to the topic, which breaks delivery対応中かも @mandar1045 が 1 日前に担当しました。 オープン
難易度 1/5 1時間未満 初心者へのやさしさ 80/100
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
phoenixframework/phoenix_live_view#4509 ·
メンテナーはふだん 1 日以内に返信