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

Ouverte
  • Quelque chose ne va pas ?
#1,565 1 commentaire 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
4/5
Temps estimé
1-2 jours
Accessibilité débutants
42/100
Type d'issue
Bug
Clarté
Plutôt claire
Activité
Active
Stack technique
github-actions, powershell, typescript
Domaine
ci-cd, testing

Piste de recherche

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.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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.

Langage dominant
TypeScript
Étoiles
5
Forks
1
Merge moyen
11 h 4 min
PR mergées (30 j)
434

Préparer son environnement

Ce projet ne fournit ni conteneur de développement, ni Dockerfile, ni guide de contribution : l'installation est à votre charge. Commencez par son README, et consultez notre guide de la première contribution pour les étapes générales.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de diffplug/dormouse

Toutes les issues de diffplug/dormouse

Issues similaires

Plus d'issues TypeScript

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.