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

Aperta
#1,565 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
1-2 giorni
Idoneità per principianti
42/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
github-actions, powershell, typescript
Ambito
ci-cd, testing

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
TypeScript
Stelle
5
Fork
1
Merge medio
11h 4m
PR unite (30g)
434

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di diffplug/dormouse

Tutte le issue di diffplug/dormouse

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.