XPath and XPath2 extractors insert a new line in the failure message which breaks CSV log file formatting for the listener.

[jkershaw3]

Using an XPath or XPath2 extractor on a http sampler. If the http sampler fails, or the response is empty, or not in the expected format, the extractor fails and appends text to its failure message This appended text inserts a new line character before the appended text. The new line character is logged by listener when logging the failure message, and breaks the file format when the listener is logging as CSV.

These files ass.setFailureMessage(thrown.getLocalizedMessage()+"\nSee log file for further details."); Line 199 XPath Extractor

ass.setFailureMessage(thrown.getLocalizedMessage()+"\nSee log file for further details."); [Line 165 XPath2] (https://github.com/apache/jmeter/blob/c7279348335b820c35ee570462cb2e0b4eb1c370/src/components/src/main/java/org/apache/jmeter/extractor/XPath2Extractor.java)

Example CSV output :

timeStamp,elapsed,label,responseCode,responseMessage,threadName,dataType,success,failureMessage,bytes,sentBytes,grpThreads,allThreads,URL,Filename,Latency,Encoding,SampleCount,ErrorCount,Hostname,IdleTime,Connect
2023/02/03 10:16:46.263,213,Test,502,FailureMessage,Thread Group 1-1,text,false,"Premature end of file.
See log file for further details.",0,0,1,1,null,,0,ISO-8859-1,1,1,MachineName,0,0

This should look like

timeStamp,elapsed,label,responseCode,responseMessage,threadName,dataType,success,failureMessage,bytes,sentBytes,grpThreads,allThreads,URL,Filename,Latency,Encoding,SampleCount,ErrorCount,Hostname,IdleTime,Connect
2023/02/03 10:16:46.263,213,Test,502,FailureMessage,Thread Group 1-1,text,false,"Premature end of file. See log file for further details.",0,0,1,1,null,,0,ISO-8859-1,1,1,SBGMLXNK094VJCR,0,0

The problem this causes is the file then cannot be processed as a valid CSV without manually correcting/removing the new lines, eg a post test JMeter report cannot be generated as it cannot read the file as a CSV format.

[FSchumacher]

You can fix this in your test plan by adding a global JSR 223 Listener, which contains the following Groovy code:

sampleResult.assertionResults.each {
    it.failureMessage = it.failureMessage
        .replaceAll("\n", "\\\\n")
}

That will replace all \n chars with an escaped variant \\n. PR #5805 should make this hack unnecessary.

[vlsi]

I think the bug report is invalid.

See https://datatracker.ietf.org/doc/html/rfc4180#section-2

Fields containing line breaks (CRLF), double quotes, and commas
       should be enclosed in double-quotes.  For example:

       "aaa","b CRLF
       bb","ccc" CRLF
       zzz,yyy,xxx

RFC suggests that it is fine to have a newline inside double-quoted field.