You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
node:test issue fixed in v20 still not working in LTS #49976
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.
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 🙂
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.
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)
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.
Activity
atlowChemi commentedon Sep 30, 2023
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 commentedon Oct 1, 2023
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 commentedon Oct 3, 2023
IMHO this issue shouldn't have been closed until it's actually resolved.
atlowChemi commentedon Oct 3, 2023
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 commentedon Oct 3, 2023
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 commentedon Oct 3, 2023
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.