[BUG] Failed archive extraction deletes the dataset cache
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 78/100
Research direction
Find _extract_archive and the download_file(..., extract=True) path used by the dataset loaders. Start by inspecting its extraction error handler and existing tests for archive failures; reproduce with a synthetic extractor that writes a partial file and raises tarfile.TarError. Done means the error still propagates while pre-existing destination contents survive and cleanup is limited to files created by that attempt.
Written by the indexing model from the issue text.
Description
Describe the bug
When archive extraction fails, _extract_archive removes the entire destination directory. The built-in dataset downloaders extract into the shared ~/.graphscope/datasets cache, so a TarError, RuntimeError, or KeyboardInterrupt during extraction can delete previously cached datasets and other files unrelated to the archive being extracted.
To Reproduce
- Put an existing sentinel file (or another cached dataset) in the extraction destination.
- Trigger an extraction failure after extraction has started (for example, a malformed or unextractable local archive).
- Observe that the error handler calls
shutil.rmtree(path)and removes the existing destination contents.
This behavior is also reproducible with a synthetic archive/extractor that writes a partial file and raises tarfile.TarError; no remote data or service is needed.
Expected behavior
A failed extraction should propagate its error without deleting pre-existing cache contents. Cleanup should be limited to files/directories created by that extraction attempt.
Environment (please complete the following information):
- GraphScope version: current
main - OS: behavior follows the shared cache extraction path; no live dataset or service was used for this report
Additional context
The built-in loaders call download_file(..., extract=True) with the common default cache_subdir="datasets", which makes the deletion affect cache entries beyond the failing archive. The target-local regression uses only synthetic files.
- Dominant language
- C++
- Stars
- 3.6k
- Forks
- 470
- PR merge metrics
- No merged PRs in 30d
Getting set up
Starts the project's dev container in your browser, under your own GitHub account.
- No 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 alibaba/GraphScope
-
stale
Difficulty 5/5 Over a week Newbie friendliness 25/100
alibaba/GraphScope#4655 · 2 comments ·
-
stale
Difficulty 5/5 Over a week Newbie friendliness 38/100
alibaba/GraphScope#4654 · 2 comments ·
-
stale
Difficulty 4/5 3-5 days Newbie friendliness 45/100
alibaba/GraphScope#4647 · 3 comments ·
-
stale
Difficulty 4/5 3-5 days Newbie friendliness 30/100
alibaba/GraphScope#4639 · 2 comments ·
-
stale
Difficulty 2/5 1-3 hours Newbie friendliness 45/100
alibaba/GraphScope#4637 · 1 comment ·
All issues in alibaba/GraphScope
Similar issues
-
category:port-update
Difficulty 2/5 1-3 hours Newbie friendliness 66/100
Maintainers usually reply within 2 days
-
MinGW build faillureOpen
Difficulty 2/5 1-3 hours Newbie friendliness 67/100
facebookresearch/faiss#5775 · 1 comment ·
Maintainers usually reply within 2 days
-
Eval bug: minimax-m3: build_moe_ffn() drops the per-expert NVFP4 scale → garbled output (M3.1 Flash)Openbug-unconfirmed
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
Maintainers usually reply within 1 day
-
bug triage
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
secondlife/viewer#6507 ·
Maintainers usually reply within 1 day
-
clang:frontend code-cleanup HLSL
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
llvm/llvm-project#235100 · 1 comment ·
Maintainers usually reply within 1 day