[Bug] Log truncation on hex output

[ArnoldNXP]

Describe the bug

When executing tests with 'trace_log': True, the output of some hex values printed in the logs/UI interface are being truncated.
See example below:

PYTHON_TEST | 2026-04-03 13:44:08.795618 | [MatterTest] 04-03 13:44:03.451 INFO "responder_random": "hex:3A2A0F9400D0373A92FEFA7201B111DD593C62CD53457B1CC000BC01F1B3E935",
PYTHON_TEST | 2026-04-03 13:44:08.795935 | [MatterTest] 04-03 13:44:03.451 INFO "responder_session_id" : "41286"
PYTHON_TEST | 2026-04-03 13:44:08.796643 | [MatterTest] 04-03 13:44:03.452 INFO }
PYTHON_TEST | 2026-04-03 13:44:08.796965 | [MatterTest] 04-03 13:44:03.452 INFO },
PYTHON_TEST | 2026-04-03 13:44:08.797272 | [MatterTest] 04-03 13:44:03.452 INFO "hex" : "15300120539A0CA1C91506591E6435E05CBF00E0967E03A5BA302B19F363BB6F432515683002203A2A0F9400D0373A92FEFA7201B111DD593C62CD53457B1CC000BC01F1B3E935250346A135042601E80300003002208089C852EBD816473C5A217B8D79FC03160D7F194A3DD557A0D7448B6070A36C183505..

Are there any settings in order to get the full output or is this behaviour not as expected

Steps to reproduce the behavior

No response

Expected behavior

No response

Log files

No response

PICS file

No response

Screenshots

No response

Environment

No response

Additional Information

No response

[rquidute]

Hi @ArnoldNXP Could you confirm that only in the UI the log is truncated? If you download the log is it displayed correctly? Could you please share the downloaded execution log?

[KishokG]

@ArnoldNXP Could you please provide the above requested information ASAP. We need to close this issue before 15th of May.

[ArnoldNXP]

Hi @rquidute @KishokG,

The log is truncated also in the downloadable log. I will attach it an example

UI_Test_Run_2026_04_03_13_43_55__TC_DD_3_34__FAIL_sendTrustedRootCert__v1.txt

Sorry for the delay

Kind regards,
Arnold

[rquidute]

Thanks @ArnoldNXP for the log file, that was very helpful!
After further analysis, the truncation is confirmed to be an upstream CHIP SDK bug, not a TH issue. Here's the root cause:

In src/tracing/json/json_tracing.cpp:518, each JSON log line is wrapped in NullTerminated(line) before being passed to ChipLogProgress:

// Current code
ChipLogProgress(Automation, "%s", NullTerminated(line).c_str());

NullTerminated is defined as StringBuilder<257> (src/lib/support/StringBuilder.h:178), which gives only 256 usable characters. A "hex" JSON line has a \t\t"hex" : " prefix of 11 chars, and when the buffer overflows AddMarkerIfOverflow() replaces the last 3 chars with .. — leaving exactly 242 hex characters visible. This matches every truncated line in the attached log file.

A possible fix would be to pass the line span directly to ChipLogProgress without wrapping it in NullTerminated:

// Suggested fix
ChipLogProgress(Automation, "%.*s", static_cast<int>(line.size()), line.data());

This avoids the 256-char copy entirely and lets the underlying logging system handle the full string. Could someone from the SDK team confirm if this is the right approach, or if there are constraints on ChipLogProgress message length that need to be considered?

CC @cecille @raju-apple @KishokG @Pradeep-grl

[andy31415]

I believe we do not use "%.*s" on purpose since that conflicts with some logging interception. project-chip/connectedhomeip#39629 did this on purpose, we should not just undo that (otherwise project-chip/connectedhomeip#39128 will appear again).

We need some other solution: split things into separate lines? Have some data that is smaller somehow and not expect overly long strings in logs? Do not test by reading logs and use some other API?

[andy31415]

@ArnoldNXP could you also explain the impact of this truncation, so we understand what a good fix would be? Do you care about data being in one line? why is the data this large? How are you using this output currently?