node:test issue fixed in v20 still not working in LTS

[andreashuber69]

Version

v18.18.0

Platform

Linux pop-os 6.4.6-76060406-generic #202307241739169531258622.04~4d8f3e9 SMP PREEMPT_DYNAMIC Thu S x86_64 x86_64 x86_64 GNU/Linux

Subsystem

node:test

What steps will reproduce the bug?

git clone https://github.com/andreashuber69/node-18-test-fail.git
cd node-18-test-fail
sudo n 18.18
npm run test

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

Always with node v18.18.0

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

Expected behavior is the same as with node v20.8.0

What do you see instead?

▶ return42
  ✔ should return 42 (0.296281ms)
▶ return42 (1.503716ms)

✖ should return 42 2 (0.09537ms)
  'test could not be started because its parent finished'

Additional information

20.4.0 apparently had the same bug: #48845, which is now fixed.

[atlowChemi]

Hi @andreashuber69, this fix was released in version 20.6.0, which was released on Sep 4th (https://github.com/nodejs/node/releases/tag/v20.6.0)

Since v18 is an LTS, commits normally take a longer time before reaching it, in order to "stay safe".
Hopefully, this issue which was fixed by #48856, will be released in v18.19.0 🙂

[cjihrig]

Yes, what @atlowChemi said 😄. I'm going to close this out since this should happen automatically and I don't think there is anything to do.

[birgersp]

IMHO this issue shouldn't have been closed until it's actually resolved.

[atlowChemi]

IMHO this issue shouldn't have been closed until it's actually resolved.

Since the fix of the bug behind this issue has already been merged to main, and is awaiting release - this is not an actionable issue, and their is no actual value in keeping it open IMHO.

[birgersp]

IMHO this issue shouldn't have been closed until it's actually resolved.

Since the fix of the bug behind this issue has already been merged to main, and is awaiting release - this is not an actionable issue, and their is no actual value in keeping it open IMHO.

But as a LTS "user", how then can I track the status of this issue. How will I know when the LTS version has this fixed?

(sorry if it seems like I'm asking rhetorically, I'm not. I'm genuinly curious)

[cjihrig]

You can watch for release issues or even look at the original PR which will have references from the release posts (you can currently see it's referenced from the v20.6.0 issue and this one). Having a separate tracking issue for every change that needs to be backported would be a pretty big headache for maintainers.