Flaky on Windows: attach_on_missing_create_is_idempotent_for_existing_file (attach_tests.rs:312)
维护者通常 2 天内回复
还没有人认领这个 Issue。
评估
- 难度
- 4/5
- 预计耗时
- 3-5 天
- 新手友好度
- 48/100
- Issue 类型
- 缺陷
- 描述清晰度
- 基本清楚
- 活跃度
- 活跃
- 技术栈
- github-actions, rust
调研方向
Start with hyperdb-mcp/tests/attach_tests.rs:312 and repeatedly run the Windows CI leg on an unchanged tree to establish whether the failure recurs. Read the adjacent locking behavior in hyperdb-mcp/src/export.rs:439-442 and the analysis from #281, then determine whether file-handle release or delete-error classification explains the assertion; done means the cause is addressed and the Windows test is reliable.
由索引模型根据 Issue 内容生成。
描述
Symptom
attach_on_missing_create_is_idempotent_for_existing_file failed on the Windows leg of a main CI run, at hyperdb-mcp/tests/attach_tests.rs:312:10:
test result: FAILED. 24 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out; finished in 60.48s
- Run: 34058959366, job
test (windows-latest)(id101555912364), at commit56bc0d0. - The same run's
test (ubuntu-latest)leg also failed, but on a different test (engine_recovers_after_hyperd_killed) — that one is now fixed by #286 / #284. This issue is only about the Windowsattach_testsfailure, which is unrelated.
It appears intermittent
test (windows-latest) passed on the next main run (34062593527, commit 61fc766) with no code change touching attach.rs. So this is one observation, not a reproducible break, and it is recorded here so the evidence is not lost if it recurs.
Why it is worth investigating rather than dismissing
The neighbouring Windows behaviour in this area is genuinely different from Unix: Windows blocks concurrent opens of a locked .hyper file (see the comment at hyperdb-mcp/src/export.rs:439-442), and the attach/CREATE DATABASE IF NOT EXISTS path is exactly where that difference shows up. An idempotency test failing only on Windows is therefore consistent with a real platform-specific race around file creation or locking, not just runner noise.
Related context: the review of #281 concluded that the export lock path is unreachable on both platforms because export_hyper deletes the target before attaching, and suggested the live Windows issue may instead be the delete step's error classification. Whoever picks this up should read that analysis, since it covers adjacent code.
What is needed
A Windows runner. This could not be reproduced locally — all recent investigation has been on macOS, and the failure has not recurred in CI since.
Suggested first steps:
- Re-run the Windows leg repeatedly on an unchanged tree to establish a rate.
- Inspect
attach_tests.rs:312to determine whether the assertion depends on file-handle release timing after the first attach.
- 主要语言
- Rust
- 星标
- 3
- 派生
- 2
- 平均合并
- 2 天 6 小时
- 30 天内合并 PR
- 34
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 没有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
tableau/hyper-api-rust 的其他 Issue
-
难度 2/5 1-3 小时 新手友好度 68/100
tableau/hyper-api-rust#294 ·
维护者通常 2 天内回复
-
难度 4/5 3-5 天 新手友好度 35/100
tableau/hyper-api-rust#311 ·
维护者通常 2 天内回复
-
难度 4/5 3-5 天 新手友好度 45/100
tableau/hyper-api-rust#305 ·
维护者通常 2 天内回复
-
Windows Named Pipe: verify DACL denies other users, and measure read-path perf for MCP workloads未关闭
难度 4/5 3-5 天 新手友好度 38/100
tableau/hyper-api-rust#302 ·
维护者通常 2 天内回复
-
难度 3/5 1-2 天 新手友好度 72/100
tableau/hyper-api-rust#300 ·
维护者通常 2 天内回复
查看 tableau/hyper-api-rust 的全部 Issue
相似的 Issue
-
RUSTSEC-2026-0348: Brotli certificate decompression can allocate up to 1 GiB before authentication未关闭
难度 2/5 1-3 小时 新手友好度 60/100
-
难度 1/5 1-3 小时 新手友好度 62/100
-
core: Amount::from_str panics on values above 21M BTC instead of returning an error可能已有人在做 @bhuvan-somisetty 今天认领。 未关闭
难度 2/5 1-3 小时 新手友好度 82/100
维护者通常 1 天内回复
-
crate: spate-s3
难度 2/5 半天 新手友好度 62/100
维护者通常 1 天内回复
-
write_iceberg ignores the table's write.parquet.compression-codec property可能已有人在做 @YuangGao 今天认领。 未关闭
难度 2/5 1-3 小时 新手友好度 82/100
Eventual-Inc/Daft#7606 ·
维护者通常 1 天内回复