console.error/warn causes problem with GCP Cloud logging

[Triskae]

Version

20.15.0

Platform

Linux redacted 6.1.85+ #1 SMP PREEMPT_DYNAMIC Sat May  4 14:32:43 UTC 2024 x86_64 Linux

Subsystem

No response

What steps will reproduce the bug?

use console.error with a nodejs program running and logging to GCP Cloud Logging

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

Use console.error and it will break the log format.

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

The expected behaviour is that nothing is added to the string being printed. Since Cloud Logging needs a valid JSON, the following log is outputed:

"[33m{ "severity": "WARNING", "timestamp": "2024-07-01T07:02:00.349Z", "context": "Main.bootstrap", "message": "API service started" }[39m"

this is NOT a valid JSON.

What do you see instead?

"[33m{ "severity": "WARNING", "timestamp": "2024-07-01T07:02:00.349Z", "context": "Main.bootstrap", "message": "API service started" }[39m"

instead of

"{ "severity": "WARNING", "timestamp": "2024-07-01T07:02:00.349Z", "context": "Main.bootstrap", "message": "API service started" }"

Additional information

Linked to this issue: 53661
And this PR: 51629

[RedYetiDev]

Duplicate of #53661

---

This is the same issue, but in a different context.

[RedYetiDev]

Shouldn't the color only be default when the stdout/stderr are TTY? I wonder #53665 is more of a bug of the TTY detection not smart enough

Linking this message from @joyeecheung, @Triskae do you have any comment on the TTY detection? If so, I apologize for prematurely closing this issue, as it seems like a duplicate

[Triskae]

TTY detection ? I'm sorry I don't have knowledge about this ?
The only thing I know is that the console.error add characters to our json string, so it's no more a json string and Cloud Logging is no more able to parse the said json ...

I don't know if it as something to do with TTY

Using console.log, solves the issue, since log doesn't seem to add anything to the printed string

[RedYetiDev]

Got it! Thanks. See the linked issue for the discussion on coloring.

[joyeecheung]

The colorization should only happen if your stderr is directed to a terminal. For cloud logging I imagine they would locally pipe the stderr somewhere else (a file or a socket or a pipe) to send the logs over to the server for the users to see in their console (e.g. the browser), in that case the stderr won’t be colorized. Unless GCP tricks Node.js into thinking the stderr is a (pseudo) TTY.