nodejs / nodejs/node

coverage testing blocked by promise should report where that promise came from

Offen
#59,940 4 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Dieses Issue hat noch niemand übernommen.

test_runner
Vorherrschende Sprache
JavaScript
Sterne
122k
Forks
37.3k
Ø Merge
4 T. 2 Std.
Gemergte PRs (30 T.)
283

Beschreibung

Version

24.8.0

Platform
macos sequioa
Subsystem

test runner

What steps will reproduce the bug?

create any dir and put a test.js file in it with content:

import test, { describe } from "node:test";
import assert from "node:assert/strict";

describe(`project testing`, async () => {
  test(`this'll hang`, async () => {
    const value = await new Promise((resolve) => {
      console.log(`looks like this'll never resolve()`);
    });
    assert.equal(value, true);
  });
});

Then run this with node --test "test.js"

Obviously this'll never finish, so hit ctrl-c, which triggers the final report and shows:

^C✖ test.js (1376.646ms)
ℹ tests 1
ℹ suites 0
ℹ pass 0
ℹ fail 0
ℹ cancelled 1
ℹ skipped 0
ℹ todo 0
ℹ duration_ms 1379.56475

✖ failing tests:

test at test.js:1:1
✖ test.js (1376.646ms)
  'Promise resolution is still pending but the event loop has already resolved'

And, sure: that's true... but this message also isn't information, because it tells us nothing that lets us fix the problem.

Which promise is still pending? Which file, line, and column and the promise invocation be found on? Because Node knows where promise call sites are, and it should include that information in the error report.

How often does it reproduce? Is there a required condition?

This is how things work right now.

What is the expected behavior? Why is that the expected behavior?

The error should be:

test at test.js:6:18
✖ test.js (1598.681125ms)
  'Promise resolution is still pending but the event loop has already resolved'

explicitly showing the line things went wrong on.

And if there is a promise pending because of some dependency of a dependency, it should show that entire trace: if test.js is awaiting getInfo() imported from ./utils.js and that calls getNetworkDeviceNames() imported from ./utils/network.js and that has a promise that never resolves, then this error should let folks find that problem:

test at test.js:6:18
  at utils.js:20:14
  at utils/network.js:112:25
✖ test.js (1598.681125ms)
  'Promise resolution is still pending but the event loop has already resolved'

Or however traces should be made to look for this functionality. The important part is that it's informative so that we can fix bugs. After all, that's the whole point of using node --test =)

Beitragsleitfaden

Beitragsleitfaden öffnen

Erste Schritte

  1. Lies das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreib ins Issue, dass du es übernimmst — das erspart doppelte Arbeit.
  3. Forke das Repository und arbeite in einem Branch.
  4. Öffne einen Pull Request, der die Issue-Nummer nennt.

Rechercherichtung

Reproduziere das Verhalten mit dem beschriebenen test.js und node --test "test.js" und beginne dann bei der Behandlung des pending-promise-Berichts durch den Test-Runner. Verfolge, wie Promise-Aufrufstellen und abhängige asynchrone Aufrufe dargestellt werden, und definiere die Ausgabe so, dass sie die Ursprungsstellen und alle relevanten Abhängigkeitsverläufe enthält.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Bewertung

Tech-Stack
javascript
Bereich
testing
Issue-Typ
Feature
Schwierigkeit
5/5
Geschätzter Aufwand
Über eine Woche
Aktivitätsstatus
Ruhig
Klarheit
Größtenteils klar
Anfängerfreundlichkeit
45/100

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.