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

Fechada
  • Algo errado?
#1,565 1 comentário 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
4/5
Tempo estimado
1-2 dias
Facilidade para iniciantes
42/100
Tipo de issue
Bug
Clareza
Razoavelmente clara
Status de atividade
Ativa
Stack de tecnologia
github-actions, powershell, typescript
Domínio
ci-cd, testing

Direção de pesquisa

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.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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.

Linguagem predominante
TypeScript
Estrelas
5
Forks
1
Merge médio
10h 54min
PRs com merge (30d)
438

Preparar o ambiente

Este projeto não oferece contêiner de desenvolvimento, Dockerfile nem guia de contribuição, então a configuração fica por sua conta: comece pelo README e veja nosso guia da primeira contribuição para os passos gerais.

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de diffplug/dormouse

Todas as issues de diffplug/dormouse

Issues semelhantes

Mais issues de TypeScript

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.