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

Abierto
  • ¿Algo no está bien?
#1,565 1 comentario 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
1-2 días
Aptitud para principiantes
42/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
github-actions, powershell, typescript
Área
ci-cd, testing

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
TypeScript
Estrellas
5
Forks
1
Merge medio
11 h 41 min
PR fusionados (30 d)
432

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de diffplug/dormouse

Todos los issues de diffplug/dormouse

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.