MongoDB: a TTL enable whose index build lands after DeleteTable dropped the collection recreates it
メンテナーはふだん 2 日以内に返信
まだ誰も着手していません。
評価
- 難易度
- 4/5
- 見積もり時間
- 3〜5日
- 初心者へのやさしさ
- 48/100
調査の方向性
Start by tracing the MongoDB UpdateTimeToLive enable path through update_ttl and create_ttl_index, then compare its catalog reads and index build with DeleteTable's collection drop. The issue points to worker_store.rs reconciliation and list_collection_names as relevant investigation entry points. Done means the race no longer leaves an orphaned data collection; reproduce the reported interleaving and confirm no orphan remains.
索引モデルが issue の本文から書いたものです。
説明
Summary
On MongoDB, UpdateTimeToLive enable runs update_ttl on the catalog document, then create_ttl_index, which reads the document and runs create_index on _ddb_<table_id>. A DeleteTable that marks the document and drops the collection between those two steps lets create_index create the collection again to hold the index; the delete then removes the only document that names it, and nothing sweeps orphaned data collections.
Measured (MongoDB 7, single-node replica set, 2026-10-26)
DeleteTable and UpdateTimeToLive enable raced through the API, twenty rounds per build: an orphaned _ddb_<id> collection with idx_ttl_ttl after 4 of 20 rounds on main. With #599 (no index DDL for a document read as DELETING, and an ACTIVE filter on create_ttl_index's catalog read) the window narrows to a catalog read taken before the mark with the create_index after the drop: 1 of 20 in one run and 0 of 80 in another.
Notes
The remaining case needs the collection drop and the index build to be ordered, or a sweep for data collections with no catalog document (worker_store.rs reconciles CREATING to ACTIVE only). list_collection_names on the data database shows the orphan.
- 主要言語
- Rust
- スター
- 517
- フォーク
- 60
- 平均マージ
- 2日 22時間
- マージ済み PR（30日）
- 25
環境構築
- Dockerfile または Docker Compose ファイルあり
- プルリクエストのテンプレートあり
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
ExtendDB/extenddb のほかの issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
メンテナーはふだん 2 日以内に返信
-
backend:mongodb bug
難易度 2/5 1〜3時間 初心者へのやさしさ 77/100
メンテナーはふだん 2 日以内に返信
-
backend:cassandra bug
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
メンテナーはふだん 2 日以内に返信
-
documentation
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
メンテナーはふだん 2 日以内に返信
-
backend:cassandra bug
難易度 2/5 1〜3時間 初心者へのやさしさ 74/100
メンテナーはふだん 2 日以内に返信
ExtendDB/extenddb の issue をすべて見る
似ている issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 85/100
FalkorDB/FalkorDB#3597 · コメント 1 件 ·
メンテナーはふだん 2 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
メンテナーはふだん 1 日以内に返信
-
needs triage
難易度 2/5 1〜3時間 初心者へのやさしさ 65/100
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 65/100
-
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
mozilla-services/syncstorage-rs#2715 ·
メンテナーはふだん 1 日以内に返信