MongoDB: a TTL enable whose index build lands after DeleteTable dropped the collection recreates it
Maintainer thường phản hồi trong vòng 2 ngày
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
- 48/100
Hướng nghiên cứu
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.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
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.
- Ngôn ngữ chính
- Rust
- Star
- 517
- Fork
- 60
- Merge trung bình
- 2 ngày 23 giờ
- Pull request đã merge (30 ngày)
- 25
Chuẩn bị môi trường
- Có Dockerfile hoặc tệp Docker Compose
- Có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- 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.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của ExtendDB/extenddb
-
backend:mongodb bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 77/100
Maintainer thường phản hồi trong vòng 2 ngày
-
backend:cassandra bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
Maintainer thường phản hồi trong vòng 2 ngày
-
documentation
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
Maintainer thường phản hồi trong vòng 2 ngày
-
backend:cassandra bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 74/100
Maintainer thường phản hồi trong vòng 2 ngày
-
[storage.cassandra] accepts unknown keys silentlyCó thể đã có người làm @LeeroyHannigan đã nhận 3 ngày trước. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
ExtendDB/extenddb#540 · 1 người được giao ·
Maintainer thường phản hồi trong vòng 2 ngày
Tất cả issue của ExtendDB/extenddb
Issue tương tự
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 79/100
Maintainer thường phản hồi trong vòng 1 ngày
-
type: enhancement
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 62/100
franciscoBSalgueiro/en-croissant#1061 ·
Maintainer thường phản hồi trong vòng 3 ngày
-
chore good first issue macros spire
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
Maintainer thường phản hồi trong vòng 1 ngày
-
groupmod -U: members change in /etc/group but not in /etc/gshadowCó thể đã có người làm @jayhemnani9910 đã nhận hôm nay. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 79/100
Maintainer thường phản hồi trong vòng 1 ngày