shell-escape.test.ts: Windows PowerShell child times out in the cmd-Session powershell test despite the warm-up

Đang mở
  • Có gì không ổn?
#1,565 1 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
1-2 ngày
Mức phù hợp với người mới
42/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
github-actions, powershell, typescript
Lĩnh vực
ci-cd, testing

Hướng nghiên cứu

Start with lib/src/lib/shell-escape.test.ts around lines 181–182 and inspect the warm-up added in #1532 and the failure context in #1564. On a Windows runner, time the listed PowerShell script pieces for each Session kind to locate the remaining cost. Done means identifying and addressing the cmd-kind delay, then confirming the test completes reliably without raising the per-shell timeout.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

tend-ci-cause

shell-escape.test.ts › reads a cmd Session's paths back literally in powershell timed out again on main after the ConvertTo-Json warm-up from #1532 landed. In run 41778763200 (Standalone Platform Check (windows-latest), head 6c252bf967ba), argvThrough's spawnSync of powershell.exe returned ETIMEDOUT at its 10s bound (shell-escape.test.ts:181-182). The next run on main passed.

The warm-up ran and reported a warm shell. Its first start took 22,940 ms, against 2.4–4.4s on the other post-#1532 runs below, and its second took 437 ms, so the step exited at its sub-second threshold. The Windows PowerShell 5.1 children around the failing test were fast:

Test (in run order) Time
runs native PowerShell startup code and exits 524 ms
passes accepted paths through dor.cmd from powershell 480 ms
reads a cmd Session's paths back literally in powershell 10,048 ms, ETIMEDOUT
reads a powershell Session's paths back literally in powershell 572 ms

A cold process start doesn't explain this, and neither does a first module load the warm-up skips: the 5.1 children on either side of the failing test, the later one also running ConvertTo-Json, took about half a second.

On the eight main runs since #1532 whose Windows job passed (41578300835 through 41711627101), the failing test took 697–799 ms each time, while reads a powershell Session's paths back literally in powershell took 303–389 ms. #1532 cut it from the 1.2–3.1s seen before, but some first-use cost the warm-up doesn't reach is still left. On a runner as slow as this one, that cost alone doesn't obviously add up to 10s (≈400 ms × 5–10 ≈ 2–4s). So either the remaining cost grows faster than the runner's slowness, or this run hit a separate stall. This run doesn't settle which.

In #1464, nedtwigg ruled out raising the per-shell bounds ("raising either bound again would only move the line"), so that isn't proposed here.

Possible next diagnostics (need a Windows runner)
  • Find what the cmd-kind 5.1 child pays that the warm-up and the powershell-kind child don't. Its script is the same argv function; only the typed arguments differ (the cmd-kind escapes of WINDOWS_LITERAL and WINDOWS_REFUSED). Timing each piece of that script in the warm-up step ([Console]::OutputEncoding, the function definition, ConvertTo-Json -Compress -InputObject @(...) over those strings) on a PR's Windows job would show which one carries the ~400 ms.
  • If the cost tracks script content rather than process start (for example, a first scan of a new script block), a warm-up that runs the exact argvThrough script for each Session kind would pay it before the tests. The check: on that PR's job, the cmd-kind test should drop to about the powershell-kind test's ~300 ms.

Cause of a failure tracked in #1564.

Ngôn ngữ chính
TypeScript
Star
5
Fork
1
Merge trung bình
11 giờ 41 phút
Pull request đã merge (30 ngày)
432

Chuẩn bị môi trường

Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của diffplug/dormouse

Tất cả issue của diffplug/dormouse

Issue tương tự

Thêm issue về TypeScript

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.