TempTableGuard is armed after the load its doc comment claims to protect
メンテナーはふだん 1 日以内に返信
まだ誰も着手していません。
評価
調査の方向性
Start in hyperdb-mcp/src/ingest.rs by reading TempTableGuard, replace_load, and merge_via_temp_table around the cited lines. Trace the guard's borrow lifetime and the load-to-cleanup boundary, then review the existing cleanup behavior and comments. Done means the documented panic coverage matches the agreed implementation, with no misleading guarantee remaining.
索引モデルが issue の本文から書いたものです。
説明
Summary
TempTableGuard's doc comment says it drops the merge temp table even if a per-format ingest "panics mid-load," but TempTableGuard::new is called after the load returns — so a panic inside the load is not covered.
The claim, twice:
// hyperdb-mcp/src/ingest.rs:162-168
/// RAII guard that ensures a temp table is dropped on **every** scope
/// exit — `Ok`, `Err`, *and* panic-unwind. Used by
/// [`merge_via_temp_table`] so an orphan `__hyperdb_merge_*` table
/// can't leak into the workspace, even if a per-format ingest path
/// panics mid-load.
// hyperdb-mcp/src/ingest.rs:260-262
/// 2. Load incoming data into a unique temp table via `replace_load`.
/// A `TempTableGuard` arms here and unwind-safely drops the temp
/// on every exit (`Ok` / `Err` / panic).
The construction site:
// hyperdb-mcp/src/ingest.rs:377-383
let tmp_result = replace_load(engine, &tmp_opts)?;
// Arm the cleanup guard immediately after the load so any later
// failure (or panic) drops the temp table on unwind. The guard
// tracks `target_db` so the DROP lands in the same DB the temp
// was created in.
let mut guard = TempTableGuard::new(engine, tmp.clone(), opts.target_db.clone());
The inline comment at :379-380 is accurate about the timing — "immediately after the load … so any later failure." The two doc comments above it are not. Everything from :383 onward genuinely is covered: the table_exists_in contract check, the column-metadata reads, the ALTER TABLE ADD COLUMN pass, and the DELETE/INSERT pair. The uncovered window is replace_load itself, which is exactly the window the doc names.
Impact
Latent. A replace_load that panics after creating the temp table but before returning leaves an orphan __hyperdb_merge_<target>_<pid>_<nanos>_<counter> table in the target database, with no cleanup and no log line — the guard's panic-path reporting at hyperdb-mcp/src/ingest.rs:216-227 was never constructed. Temp names are unique per call, so these accumulate rather than colliding: one per panicking merge, until someone notices them in a table listing. No data corruption and no wrong answers. The real cost is a doc comment that will convince the next reader the window is already closed.
Fix direction
This is not a one-line move. The guard borrows the engine immutably for its lifetime:
// hyperdb-mcp/src/ingest.rs:172-173
struct TempTableGuard<'a> {
engine: &'a Engine,
while replace_load needs an exclusive borrow (F: FnOnce(&mut Engine, &IngestOptions), hyperdb-mcp/src/ingest.rs:304). Constructing the guard first would hold a shared borrow across the closure's exclusive one, which the borrow checker rejects — presumably why it sits where it does.
So the choice is either to restructure so the guard can span the load — have it hold something cheaply shareable instead of an &Engine, or register the temp name in a scope-owned list that a single outer guard drains — or to correct the two doc comments to promise only what the code delivers, namely coverage from the load's return onward. The doc fix is small and honest; the restructure closes the window but is worth weighing against how likely a per-format loader is to panic mid-load in the first place.
- 主要言語
- Rust
- スター
- 2
- フォーク
- 2
- 平均マージ
- 12時間 2分
- マージ済み PR（30日）
- 60
環境構築
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
tableau/hyper-api-rust のほかの issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
tableau/hyper-api-rust#294 ·
メンテナーはふだん 1 日以内に返信
-
難易度 4/5 3〜5日 初心者へのやさしさ 35/100
tableau/hyper-api-rust#311 ·
メンテナーはふだん 1 日以内に返信
-
難易度 4/5 3〜5日 初心者へのやさしさ 45/100
tableau/hyper-api-rust#305 ·
メンテナーはふだん 1 日以内に返信
-
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 ·
メンテナーはふだん 1 日以内に返信
-
難易度 3/5 1〜2日 初心者へのやさしさ 72/100
tableau/hyper-api-rust#300 ·
メンテナーはふだん 1 日以内に返信
tableau/hyper-api-rust の issue をすべて見る
似ている issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 74/100
trailofbits/dylint#2107 ·
メンテナーはふだん 1 日以内に返信
-
area:cli bug good first issue priority:medium
難易度 2/5 1〜3時間 初心者へのやさしさ 90/100
メンテナーはふだん 1 日以内に返信
-
arrays_zip with two same-named inputs fails with "ArrowArray struct has 2 children (expected 1)"オープンbug requires-triage
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
apache/datafusion-comet#6251 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
メンテナーはふだん 1 日以内に返信
-
bug false-positive harper-core linting
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
Automattic/harper#4471 ·
メンテナーはふだん 1 日以内に返信