`.timeLimit` 對卡在同步 C call 的 test body 只記 issue、不解除阻塞——三個檔案的「掛住→紅燈」宣稱不成立

[kiki830621]

Problem

#57 verify 的 DA 實測：swift-testing 的 .timeLimit(.minutes(1)) 掛在一個同步阻塞於 C call（waitUntilExit / blocking read）的 test body 上，60 s 時記錄一則 issue，但 body 繼續跑滿 150 s——它不會解除阻塞、不會終止 body。

repo 內以此為「掛住會轉成真的紅燈」的既有站點（grep -rn timeLimit Tests/）：

• Tests/LTMQueryTests/ConservativeStrategyTests.swift:202 註解逐字寫「它回歸時的症狀是掛住而不是失敗，.timeLimit 把它轉成一個真的紅燈」
• Tests/LTMEvalTests/InterleavingTerminationTests.swift（4 條）
• Tests/LTMMemoryTests/CorpusContainmentTests.swift（4 條，FIFO 阻塞情境）
• Tests/LTMIndexTests/IndexBuilderTests.swift:1086

.timeLimit 對純 Swift 迴圈的 body 是否能中止，與對阻塞 syscall 的 body 行為可能不同——DA 只量了後者。各站點要分別驗。

Type

bug（測試基礎設施的假宣稱）

Expected

1. 逐站點實測：把 body 換成對應形狀的永久阻塞（純迴圈 vs blocking syscall），看 .timeLimit 是否讓整個 swift test 在限時內結束並紅。
2. 對不成立的站點：改成能真正解除阻塞的機制（子行程 → terminate/kill；FIFO → O_NONBLOCK 或 alarm），註解改真。
3. 對成立的站點：註解補上「限純 Swift body」的界線。

Actual

註解宣稱「掛住 → 紅燈」，至少對 blocking-syscall 形狀不成立（DA 實測）。#57 的測試已改用有界等待＋親手 terminate/kill，不再依賴 .timeLimit。

Source: surfaced during /idd-verify #57 (DA lens)

---

Current Status

• Phase: diagnosed
• Updated: 2026-09-07（diagnosis 已 post；實測：純 Swift spin 與阻塞 C call 兩種形狀 timeLimit 都只記 issue、body 跑滿；13 站點／5 檔；Complexity Plan；Conflict Class C（與 每 build 固定項改維護式記帳——#44 閘的 Q1 逐列探查與 chunkCount() 全表 COUNT 隨索引總量成長（設計決定） #61 共 IndexBuilderTests）

Tasks

• 1. helper expectCompletes(within:_:)：detached thread＋有界 semaphore，逾時具名失敗並 return
• 2. 13 站點改用 helper、移除 .timeLimit
• 3. 註解改真（ConservativeStrategyTests:202、CorpusContainmentTests:171、MCPStdoutTests:85 的「三條」→ 13）
• 4. 變異驗收：拿掉生產守衛 → N s 內紅且套件結束（每檔至少一條）
• 5. helper 位置決定（共用 test target vs 各檔一份）

[kiki830621]

Diagnosis

Type

bug（測試基礎設施的假宣稱）

Root Cause / Analysis

實測（swift-testing，Swift 6.3.3，暫時 probe、跑完即刪）——兩個 body 各跑 75 s，掛 .timeLimit(.minutes(1))：

body 形狀	60 s 時	body 何時結束	swift test 何時結束
A：純 Swift busy loop（不呼叫 C、不檢查 cancellation）	記錄 issue「Time limit was exceeded: 60.000 seconds」	75 s（跑滿）	75 s
B：阻塞 C call（sleep(75)）	同上	75 s（跑滿）	75 s

所以 issue 的「兩種形狀要分別驗」驗完了：結論相同。.timeLimit 對任何一種 body 都只記 issue、不終止——swift-testing 的時限是透過 Task cancellation 實作的，而 cancellation 是協作式：純 Swift 迴圈不檢查 Task.isCancelled 就不會停，C call 更不會。「掛住 → 紅燈」這句宣稱的真實語意是：issue 會在 60 s 被記錄，但整個 swift test 要等 body 自己結束——回歸若是真的無限迴圈／永久阻塞，套件永遠跑不完，紅燈只存在於一個永遠不會結束的 run 的 log 裡。對 CI 而言那是 hang，不是 fail。

13 個站點的分類（grep -rn timeLimit Tests/）：

檔案	站點	回歸時的 body 形狀	註解宣稱
LTMEvalTests/InterleavingTerminationTests.swift	4	純 Swift spin	隱含「不會 spin」
LTMQueryTests/ConservativeStrategyTests.swift	2	純 Swift spin	逐字宣稱「.timeLimit 把它轉成一個真的紅燈」（:202）——假
LTMMemoryTests/EventStoreTests.swift	2	阻塞 flock(LOCK_EX) C call	「取不到鎖就拋」由 LOCK_NB 輪詢保證；timeLimit 是備援
LTMMemoryTests/CorpusContainmentTests.swift	4	阻塞 open() C call	誠實：「症狀是測試套件跑不完，本身就是訊號」（:171）——但仍掛 timeLimit 暗示會紅
LTMIndexTests/IndexBuilderTests.swift	1（:1086）	阻塞 flock C call	標題「named failure not a silent hang」

共同點：這 13 條測試的真正守衛都在生產程式碼裡（LOCK_NB、O_NONBLOCK、requireFiniteBaseScores、去重檢查），.timeLimit 只是在守衛回歸時的第二道——而它剛好在最需要的那一刻（真的無限阻塞）不起作用。這不是 bug 的來源，是「有備援」的假象。

已有的正確形狀：MCPStdoutTests.swift:80-86（#57）——有界等待、deadline 到就親手 terminate/kill 子行程，並明寫「不用 .timeLimit」。那段註解說「repo 內三條既有測試」——實際是 13 條、5 個檔（本 issue 順手修正那個數字）。

Impact

• 影響的檔案：新 Tests/TestSupport/BoundedRun.swift（或各模組各一份極小 helper——見 Strategy 的決定點）、上表 5 個測試檔的 13 個站點、MCPStdoutTests.swift:85 的數字。不動生產程式碼。
• 影響的使用者流程：無；影響的是 CI 在這 13 條回歸時是 hang 還是 fail。

Strategy

• 寫一個測試用 helper expectCompletes(within: seconds, _ body: () throws -> Void)：把 body 丟到 detached thread（不是 Task——Task 的取消同樣協作式，而 thread 我們不取消、只不等）、用 DispatchSemaphore.wait(timeout:) 有界等；逾時 → Issue.record 具名失敗並 return（卡住的 thread 留著，行程結束時被回收；純 Swift spin 會燒一顆核心到 run 結束——這是刻意接受的代價，寫進 helper 註解）
• 13 個站點改用 helper（限時可縮到秒級，不必等 60 s）；移除 .timeLimit（留著會讓讀者以為它有用）
• 註解改真：ConservativeStrategyTests.swift:202 那句改成「回歸時 body 不會自己結束；helper 在 N s 後具名失敗」；CorpusContainmentTests.swift:171 保留誠實那句、去掉 timeLimit 的暗示；MCPStdoutTests.swift:85 的「三條」改「13 條、5 檔」並指回本 issue
• 變異：拿掉任一生產守衛（例 O_NONBLOCK）→ 對應測試在 N s 內紅且套件結束（不是 hang）；這是本 issue 的驗收，每個檔至少驗一條
• helper 放哪：各 test target 目前沒有共用 support target——決定點：(a) 加 Tests/TestSupport 共用 target（Package.swift 動一處）或 (b) 5 個檔各放一份 10 行的 helper。建議 (a)；(b) 是「同一件事五份實作」，CLAUDE.md 點名的漂移形狀

Conflict Class

C_shared_module_coord —— 共享資源：Tests/LTMIndexTests/IndexBuilderTests.swift（#61 也要在同檔加 trigger 等價測試）與 Package.swift（若選 (a) 加 test target；#61 不動它）。與 #61 相鄰序列化。其餘四個測試檔無他人。

Complexity

Plan

• Layer 1 未命中（改的是測試行為，不是 prose）。Layer 2 未命中（無對外 API）。
• Layer P：cross-file refactor 無 external contract change（一個 helper 被 13 個站點用）＋ decision-heavy（thread vs Task、helper 放哪、限時多少、leaked thread 政策）。
• Hard-gate: triggered — 單一概念（有界等待 helper）散佈 5 個測試檔＋helper 檔＋可能 Package.swift；shared abstraction：新 helper 被 13 個 caller 用。結論 Plan。

→ /idd-plan #59

Risks

• leaked thread 在純 Swift spin 的回歸下會燒 CPU 直到 run 結束；若同一 run 有多條回歸就多顆核心——可接受（那是回歸時才發生），但 helper 註解要明寫。
• DispatchSemaphore 在 Swift 6 strict concurrency 下與 Task 混用會被警告（阻塞 cooperative pool）；helper 只在同步 test body 內、用 Thread 起 body，不在 Task 裡 wait——plan 階段確認 6.3 的 warning 面。
• 把 60 s 的 .timeLimit 換成秒級限時，在 CI 負載重時可能假紅——限時要留餘裕（建議 10 s），並在 helper 訊息裡印實際等了多久。

Residue

(none)

Vagueness Pre-check

• V1: 2 — 要做什麼明確：逐站點驗證、改成真能解除阻塞的機制、註解改真。
• V4: 2 — 完成定義具體（「限時內結束並紅」可機械驗收）。
• Triggered: no — both axes ≤ 3

Sister Concerns Filed (mid-diagnose, v2.47.0+ #528)

• Not filed: 「MCPStdoutTests.swift:85 寫『三條』實為 13 條」——併入本 issue Strategy 第 3 項。
• Not filed: 「純 Swift spin 也不會被 timeLimit 中止」——本 issue 的實測結論，已寫入 diagnosis 主文。

[kiki830621]

Dashboard — #59

現況：已 diagnose（2026-09-07）。實測兩種形狀（純 Swift spin、阻塞 C call）：.timeLimit 都在 60 s 記 issue、body 都跑滿 75 s——它從不終止 body，真無限阻塞時套件永遠跑不完。13 個站點／5 檔的真守衛都在生產碼，timeLimit 只是假備援。修法：有界等待 helper（detached thread＋semaphore）取代 .timeLimit。Complexity Plan，Conflict Class C（與 #61 共 IndexBuilderTests）。

你該做什麼：審 diagnosis；同意的話 idd-all 會接 /idd-plan #59。