console.log(response.body) can break the console output

[sniku]

It seems that the console.log() doesn't do any shell escaping and therefore, the control characters can break the terminal output.

Environment

• k6 version: 0.28
• OS and version: Linux / bash

Expected Behavior

I expected the control characters (\r etc) to be escaped before printing.

Actual Behavior

console.log(resp.body) prints about 6 empty lines, and can sometimes swallow correctly printed text around it.

Steps to Reproduce the Problem

k6 run script.js

import http from 'k6/http'

export default function testSuite() {

    let resp = http.request('post', `https://test-api.k6.io/user/register/`);

    console.log(`status: "${resp.status}"`);
   
    console.log("======= START console.log(resp.body.replace(...) - works ==========")
    console.log(resp.body.replace(/\r\n/g, "\n")); // works
    console.log("======= END ==========\n")

    console.log("======= START console.log(resp.body) - doesn't work at all  ==========")
    console.log(`body full: ${resp.body}`); // prints empty space.
    console.log("======= END ==========\n")
}

The cloud version of logs handles it better.

[siddhant94]

hey @sniku , @MStoykov Is this bug resolved? I was not able to reproduce the empty lines. Attaching the screenshot

[sniku]

@siddhant94 this isn't fixed.

It's interesting to see that the bug is not reproducible in VSCode (your screenshot). Try running it in a real shell, below is a screenshot from bash.

[siddhant94]

hey @sniku , I am attaching relevant links to which this issue is related. Logrus PR Logrus Issue

Adding DisableQuote:false to the logrus instance formatting seems to solve this. Coupe of questions, one is terminal the only place where this is written? Or rather does this log info is for human consumption only? And second one is, what would be your preference as to put this disable quote option for formatting, one option is to set this only in /k6/js/console.go in func (c console) log() or currently I have added to cmd/run.go as shown in below snippet.

Any suggestions/preference?

RunE: func(cmd *cobra.Command, args []string) error {
		// TODO: don't use a global... or maybe change the logger?
		logger := logrus.StandardLogger()
		logger.SetFormatter(&logrus.TextFormatter{DisableQuote: false})

[na--]

Erm, I'm wondering if this should even be fixed :confused: Printing binary data in a terminal has always had the possibility of breaking its output, I don't see why k6 should be an exception. Users can quote binary data before printing, if they want to avoid it. Or they can get escaped console output with --logformat=json. Given that k6 can't write to files, forwarding unescaped --logformat=raw data to a file might have its uses...

[sniku]

Erm, I'm wondering if this should even be fixed confused Printing binary data in a terminal has always had the possibility of breaking its output, I don't see why k6 should be an exception.

I think it's common for k6 users to console.log(response.body) for debugging purposes so having a good experience for this basic use case would be nice. It's true that response.body can be binary, but most of the time it's just HTML or JSON. I think that printing text with \r\n should not break the terminal output.

[na--]

Hmm I've removed this from hacktoberfest, sorry, and I'm keeping the evaluation needed label. This definitely deserves some further consideration and thinking how we should implement it...

I think it would be fine to automatically escape control characters if the place we're outputting the console messages is a TTY and the user has not used --logformat=raw.

But, even so, judging by the mess of setupLoggers(), there is some refactoring to do... There isn't proper validation for --logformat and --log-output, and I even spotted a small recent bug. Starting with k6 v0.28.0, you can redirect the console messages to stdout with --log-output=stdout, but the color support always seems to check if stdErr is a TTY: https://github.com/loadimpact/k6/blob/ef717e1af2a92d35d39a3d815a69b6ab6b8c65e1/cmd/root.go#L228

[joephilanthropi]

Is there plans to address this?

[ppamorim]

I am experiencing the same issue.