Outbound group sessions are invalidated upon reception of a duplicate state event
まだ誰も着手していません。
評価
調査の方向性
mautrix/client/state_store/abstract.py の update_state() と mautrix/client/client.py での登録から始め、次に mautrix/crypto/machine.py の handle_member_event() と、そこでの登録を追跡します。同時ロードおよび比較のパスを、参照されているコミットと比較します。重複した Membership イベントによって送信グループセッションが無効化されなくなり、実際の状態変更では引き続き無効化されるようになれば完了です。
索引モデルが issue の本文から書いたものです。
説明
Mautrix uses lazy membership loading, which causes synapse to oftentimes send state events to the client, that the client has already received. Upon reception of a state event, mautrix invalidates all outbound group sessions. This is the correct thing to do, but because synapse frequently sends duplicate state events, mautrix invalidates outbound group sessions all the time.
A fix for this has first been implemented in 72fb0f61f2a8cf8f062ddb8bacaa98ef4cbd0aa5. This fix relies on storing the most recent membership event as an attribute of the event and then later comparing this stored event to the received event and ignoring the received event if they are equal:
https://github.com/mautrix/python/blob/3e22e6192e2a9d208b9e7ea159b2169daa60a1ce/mautrix/client/state_store/abstract.py#L146-L148
https://github.com/mautrix/python/blob/3e22e6192e2a9d208b9e7ea159b2169daa60a1ce/mautrix/crypto/machine.py#L193-L200
The problem is, that loading the most recent membership event and comparing the stored membership event happens in different event handlers, which are executed concurrently.
The most recent membership event is loaded in the update_state() event handler, which is registered here:
https://github.com/mautrix/python/blob/3e22e6192e2a9d208b9e7ea159b2169daa60a1ce/mautrix/client/client.py#L31
Comparing the received membership event against the most recent one happens in handle_member_event(), which is registered here:
https://github.com/mautrix/python/blob/3e22e6192e2a9d208b9e7ea159b2169daa60a1ce/mautrix/crypto/machine.py#L109
While the update_state() handler is executed first, execution is interrupted once the most recent membership event is loaded via await self.get_member(), as this loads the event from the database, which takes some time. In the meantime, handle_member_event() becomes active and attempts to compare the received membership event against the most recent one, which hasn't yet been loaded from the database. As a result, the comparison fails and the outbound session is invalidated.
I implemented a hacky fix for this in https://github.com/jkhsjdhjs/mautrix-python/commit/e7c1921fb8f52549baf09ed2784fe46573964911, as I don't know a good way to fix this properly.
- 主要言語
- Python
- スター
- 249
- フォーク
- 84
- PR マージ指標
- 30日以内にマージされた PR はありません
コントリビューションガイド
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
mautrix/python のほかの issue
-
難易度 5/5 1週間以上 初心者へのやさしさ 30/100
-
bug
難易度 2/5 1〜3時間 初心者へのやさしさ 45/100
-
難易度 5/5 1週間以上 初心者へのやさしさ 25/100
-
難易度 4/5 3〜5日 初心者へのやさしさ 30/100
-
難易度 4/5 3〜5日 初心者へのやさしさ 38/100
似ている issue
-
bug
難易度 2/5 1〜3時間 初心者へのやさしさ 90/100
learningequality/ricecooker#747 ·
-
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
BSData/horus-heresy-3rd-edition#3171 ·
-
enhancement
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
-
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
run-llama/llama_index#23199 ·
-
難易度 2/5 1〜3時間 初心者へのやさしさ 84/100
KhronosGroup/glTF-Blender-IO#2769 ·