Excessive escape characters?

[TheOnlyWei]

The value returned below returns with excessive escape characters: https://github.com/onsi/ginkgo/blob/a8e5f3d44fa41a45a078265cc972c7444466899c/types/types.go#L328C27-L328C27 From my tests, the above returns excessive escape characters compared to the value represented in the Ginkgo output logs. We throw debug errors whenever there is a failure, and the debug errors contains many lines and characters. This creates an unreadable wall of text that is returned by the above function.

Example:

...
\\\"foo\\\":\\\"bar\\\"}\\n
...
:{\\\"k:{\\\\\\\"type\\\\\\\":\\\\\\\"fizz\\\\\\\"}\\\"
...

[onsi]

Hey can you share a little more detail? what test are you running to generate this output? Can you produce a minimal reproducer?

[TheOnlyWei]

@onsi The value is returned by specReport.FailureMessage() in the below code snippet from our test. The tests we ran are on Azure CLI commands (https://learn.microsoft.com/en-us/cli/azure/get-started-with-azure-cli). The excessively escaped characters occurred inside the debug messages of Azure CLI commands output by specReport.FailureMessage(), which include HTTP request and response JSON strings. Those characters are not escaped in the regular Ginkgo output but are escaped in specReport.FailureMessage() output, so it's not an issue with the command I am using. Was wondering if there is a configuration to prevent the escape characters if this is not a bug.

var _ = ReportAfterSuite("...", func(report Report) {
        ...
	for _, specReport := range report.SpecReports {
		t := framework.Test{}
		t.Errors = 0
		if specReport.Failed() {
			...
			t.Errors = 1
			t.Failures = append(t.Failures, framework.Failure{
				Name: specReport.FailureMessage(),
				Type: specReport.LeafNodeText,
			})
		}

[onsi]

hey @TheOnlyWei - sorry for the delay. specReport.FailureMessage() doesn't do any encoding. it's just returning the failure message string which shouldn't have any escapes in it. I notice you're appending to a t := framework.Test struct which is not something I'm familiar with. Could it be that when that t instance is emitted or encoded this escaping is happening? can you replace specReport.FailureMessage() with "{\"foo\": \"bar\"}" or something to see if it gets escaped?

Alternatively you can further try to isolate this by simply calling Fail("test") in one of your tests to see how "test" gets rendered. If you're using Gomega, Gomega does insert some whitespace to format its failure messages - but that's it. There shouldn't be much escaping going on beyond that.