Skip to content

Commit 993e39a

Browse files
committed
docs(plan): adopt two corrections from the parallel Windows investigation
bitkyc08-arch investigated the same CI red independently in devlog/_plan/260731_windows_bun_stability/. The conclusions converge, and two details there are more accurate than mine. panic(thread is not a usable fingerprint: the thread token varies by run (panic(thread 2852) in one, panic(main thread) in another). The stable strings are 'oh no: Bun has crashed' and 'Internal assertion failure'. Timeouts do not appear on the (fail) line. They print separately as '^ this test timed out after Nms', so grepping (fail) alone cannot tell a budget overrun from a logic failure. Checking run 30618324009 with the right pattern shows all three failures were budget overruns, and executeArchivedCleanup blew a 20s budget -- the runner was that slow, not the test that wrong. That unit also sampled 10 failing runs to establish crash and test-failure are mutually exclusive; I had looked at 2. Keeping both documents. This one records what this round changed; that one is the mode taxonomy and the candidate fixes.
1 parent ee7c252 commit 993e39a

1 file changed

Lines changed: 32 additions & 0 deletions

File tree

devlog/_plan/260731_pr_issue_triage_round/050_windows_ci_flake_rca.md

Lines changed: 32 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -160,3 +160,35 @@ macOS의 claude 핑 테스트도 같은 계열이다. 90ms 침묵에 25ms 핑
160160

161161
2번을 확인 안 하면 그냥 침묵이다. `020`에서 무력한 테스트 세 건을 지적해놓고
162162
같은 짓을 하는 셈이 된다.
163+
164+
## 병행 단위 — `260731_windows_bun_stability`
165+
166+
같은 문제를 다른 사람(`bitkyc08-arch`)이 독립적으로 조사해
167+
`devlog/_plan/260731_windows_bun_stability/000_research.md`에 남겼다. 결론이
168+
수렴한다 — 하나의 플레이크가 아니라 원인이 다른 여러 모드라는 것.
169+
170+
그쪽이 **더 정확한 부분이 둘** 있어서 여기 반영한다.
171+
172+
**1. 크래시 지문으로 `panic(thread` 를 쓰면 안 된다.** 스레드 표기가 런마다
173+
다르다 — `30613324981``panic(thread 2852)`, `30606401943``panic(main thread)`다.
174+
안정적인 지문은 `oh no: Bun has crashed` 또는 `Internal assertion failure`다.
175+
내가 위에서 쓴 `panic(thread N)` 표현은 그대로 두되, **grep은 저 두 문자열로 하라**
176+
게 맞다.
177+
178+
**2. 타임아웃은 `(fail)` 줄에 안 찍힌다.** 별도 줄에 `^ this test timed out after
179+
5000ms.`로 나온다. `(fail)`만 grep하면 예산 초과인지 로직 실패인지 구분을 못 한다.
180+
확인해보니 `30618324009`이 정확히 그렇다:
181+
182+
```
183+
^ this test timed out after 5000ms. (server-auth ×2)
184+
^ this test timed out after 20000ms. (executeArchivedCleanup)
185+
```
186+
187+
세 건 다 **예산 초과**였다. 로직 결함이 아니다. 특히 `executeArchivedCleanup`
188+
이미 20초를 받고도 넘겼다 — 러너가 그만큼 느렸다는 뜻이다.
189+
190+
**표본 크기도 그쪽이 낫다.** 실패 런 10건에서 모드 A(크래시)와 모드 B(테스트 실패)가
191+
상호 배타적임을 확인했다. 나는 2건만 봤다.
192+
193+
두 문서를 합치지 않고 나란히 둔다. 이 문서는 **이 라운드에서 무엇을 고쳤는지**
194+
기록이고, 그 문서는 **모드 분류와 개선 후보**의 조사다. 목적이 다르다.

0 commit comments

Comments
 (0)