storage-sqlite: a restore slot test checks the slot before the copy frees it
Maintainers usually reply within 4 days
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 82/100
Research direction
Read crates/storage-sqlite/src/backup.rs, especially backup::restore_tests::reconciler_fencing::a_running_restore_holds_its_slot_and_is_not_listed_dead_by_its_heartbeat, and compare its slot check with the existing wait loop on engine.job_slots.holds(&slot). Add a time limited wait after wait_for_copy returns, then run that test; done means it reliably waits for the restore slot to be freed before asserting.
Written by the indexing model from the issue text.
Description
backup::restore_tests::reconciler_fencing::a_running_restore_holds_its_slot_and_is_not_listed_dead_by_its_heartbeat (crates/storage-sqlite/src/backup.rs) failed in run-tests (stable) of job 127447427993, on #868 on 5 November 18:33 UTC, with the slot is freed with the claim when the copy ends. #868 does not change storage-sqlite, and the rerun of the job passed. In the 184 completed runs of test.yml before it, from 3 to 5 November, this test did not fail.
The test calls wait_for_copy, which returns when the target's table_status is ACTIVE. Then it asserts at once that job_slots no longer holds the restore's slot. The copy commits ACTIVE in its own transaction and returns. The slot is freed later, when the job's claim (crates/storage-sqlite/src/backup_catalog.rs) is dropped. So a check that runs between the two sees the slot held.
A fix that keeps the assertion is to wait, with a time limit, for the slot to be freed after wait_for_copy returns. Another test in the same module already waits that way, in a loop on engine.job_slots.holds(&slot).
- Dominant language
- Rust
- Stars
- 517
- Forks
- 60
- Avg merge
- 5d 3h
- Merged PRs (30d)
- 79
Getting set up
- Ships a Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from ExtendDB/extenddb
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
Maintainers usually reply within 4 days
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
Maintainers usually reply within 4 days
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
Maintainers usually reply within 4 days
-
tests: two race tests share one boto3 client across threads and failed with TLSV1_ALERT_DECODE_ERROROpenci:stability
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
Maintainers usually reply within 4 days
-
documentation
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
Maintainers usually reply within 4 days
All issues in ExtendDB/extenddb
Similar issues
-
enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
-
bug order-flow studies ui
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
userFRM/egui-charts#2417 ·
Maintainers usually reply within 1 day
-
In a plain-text message, Font, Font Size, Font Color and Text Highlight Color stay livePossibly taken @ragelfundionctrumnar claimed this today. Open
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
UCS-Care-Group/mailcraft#862 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
smoltcp-rs/smoltcp#1243 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day