Wrong behaviour of console.log in node 10

[oscaretu]

• Version: 10.20.1
• Platform: Windows 10 Home, 64 bit
• Subsystem: Windows on Linux (WSL)

What steps will reproduce the bug?

If you execute this program with v10.20.1:

'use strict';

let dead = Buffer.alloc(1023, 'DEADBEEF', 'hex');

console.log("\n* The next one shows an 'n' suffix:\n");

console.log(dead.readBigUInt64BE(6) );

console.log("\n* The next one doesn't show an 'n' suffix:\n");
console.log('dead.readBigUInt64BE(6) [dec]: ', dead.readBigUInt64BE(6) );

console.log("\n => The only difference is that before the number a text was shown. Is right this behaviour?\n");

console.log("* But it shows the 'n' suffix in I invert the order of the two parameters:\n");
console.log(dead.readBigUInt64BE(6), " <= dead.readBigUInt64BE(6) [dec]\n");

you get

* The next one shows an 'n' suffix:

13758460224454254253n

* The next one doesn't show an 'n' suffix:

dead.readBigUInt64BE(6) [dec]:  13758460224454254253

 => The only difference is that before the number a text was shown. Is right this behaviour?

* But it shows the 'n' suffix in I invert the order of the two parameters:

13758460224454254253n ' <= dead.readBigUInt64BE(6) [dec]\n'

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

It appears always if I use the v10.20.1 version. It doesn't happen if I use versions v12.18.3 or v14.7.0

What is the expected behavior?

You shoudn't get this:

dead.readBigUInt64BE(6) [dec]:  13758460224454254253

but

dead.readBigUInt64BE(6) [dec]:  13758460224454254253n

(with a "n" suffix at the end of the number)

And you shouldn't get this:

' <= dead.readBigUInt64BE(6) [dec]\n'

but this (without single quotes, and with a new line instead of \n):

 <= dead.readBigUInt64BE(6) [dec]

[ghost]

@oscaretu thanks for the issue :)
Indeed. I'm able to reproduce this. The same problem is present in node 10.22.0, I've checked it.

node 12.18.3 which is the current Active LTS does not have this error though. I believe we'll need to check out the difference between the two and make the required changes.
I'll look into the source code a bit later, have no time for this right now.

[ghost]

@addaleax can you assign this one to me?

[addaleax]

@iandrc Sure – just be prepared, I think this may be something that might intentionally have been changed as a semver-major commit (i.e. not backportable).

[ghost]

@addaleax so, what should we do in such a case? Would we need to add a different logic for this one or leave "as is?"

[addaleax]

@iandrc That depends on the commit, e.g. whether it’s partially backportable or not. But probably leave it as-is, yes.

[ghost]

@addaleax

Currently, I'm not as familiar with node internals as I wish but... I've taken a look at the issue. Tbh, I didn't find any specific change that may cause it.

Yet, I observed one interesting thing. If we run the proposed code, we'll see the output @oscaretu observed:

console.log('dead.readBigUInt64BE(6) [dec]:  ', dead.readBigUInt64BE(6) );
// dead.readBigUInt64BE(6) [dec]: 13758460224454254253

However, if we'll add some formatting specifiers, it'll work just fine. For example, the lines:

console.log('dead.readBigUInt64BE(6) [dec]: %d', dead.readBigUInt64BE(6));
// or
console.log('dead.readBigUInt64BE(6) [dec]: %o', dead.readBigUInt64BE(6));

print the line you expect to see, namely:

dead.readBigUInt64BE(6) [dec]: 13758460224454254253n

I guess, the problem is somehow related to console.log()'s format specifiers. Still, not quite sure

[richardlau]

Glancing through the changelog for 12, I'd guess #25046 (explicitly marked (dont-land-on-v10.x) and/or #23162 (marked semver-major, see also discussion in #29592) could be at play.

To set some expectations, Node.js 10.x is in maintenance now, which means there are no scheduled further updates planned (it will continue to get critical security fixes up until it's End-of-Life in April 2021). If there are small, low risk changes the Release WG may allow them to land on the v10.x-staging branch.

[ghost]

@richardlau yeah, you're probably right. I missed those changes. Thanks for helping me out. Could you, please, explain how did you search? Because I have no idea how to search through commits more efficiently. Just curious.

Yeah, I believe that we won't change anything for node v10.x. I mean it's not marked dont-land-on-v10.x for no reason. This problem is solved in newer versions, and we've provided several options that may be helpful for @oscaretu.

So, could we close this one? What do you think?

[richardlau]

I vaguely remembered #29592 (not specifics, just the general gist of it) and CTRL+F searched through https://github.com/nodejs/node/blob/master/doc/changelogs/CHANGELOG_V12.md for console and then util. Probably not the most efficient way.

If those two PRs (or one of them) were the fix then it's highly unlikely we'd backport to 10.x.

[ghost]

In this case, we, probably, can close the ticket.

[lundibundi]

I don't think there is anything actionable left here as per the discussion above. Closing for now.