Skip to content

terratest_log_parser Parser incorrectly assigns logs from parallel tests #1605

@FarhanAhmed786

Description

@FarhanAhmed786

Bug: Parser terratest_log_parser incorrectly assigns logs from parallel tests

Description

When parsing test output from parallel Go tests, terratest_log_parser misattributes log lines from one test to another test's output file. This happens because the parser relies on a heuristic that assumes sequential stdout lines belong to the same test, but parallel test execution causes stdout interleaving.

Steps to Reproduce

  1. Run multiple tests in parallel using t.Parallel()
  2. Each test generates continuous log output using terratest's logger
  3. Capture output: go test -v ./... | tee test_output.log
  4. Parse logs: terratest_log_parser -testlog test_output.log -outputdir output/
  5. Inspect generated per-test log files

Expected Behavior

Each test's log file should contain only logs from that specific test.

Actual Behavior

Log files contain interleaved output from multiple tests. Test result markers (=== RUN, --- FAIL, --- PASS) from one test appear in another test's log file.

Evidence

Example 1: TestNginxFailService.log contains logs from TestNginxMultipleReleases

TestNginxFailService 2025-10-23T21:02:52Z logger.go:66: Running command kubectl...
=== NAME  TestNginxMultipleReleases/nginx-multi-0-cxog3r
--- FAIL: TestNginxMultipleReleases (0.06s)
TestNginxFailService 2025-10-23T21:02:53Z logger.go:66: NAME    READY   STATUS...

Example 2: TestNginxFailDeployment.log contains logs from TestNginxComplexSubtests

TestNginxFailDeployment 2025-10-23T21:02:58Z sample_4_test.go:52: Deployments check completed
TestNginxFailDeployment 2025-10-23T21:02:58Z logger.go:66: Running command kubectl...
=== NAME  TestNginxComplexSubtests/group/TestService
TestNginxFailDeployment 2025-10-23T21:03:01Z sample_4_test.go:50: Resource enumeration...

Example 3: Raw stdout showing interleaving

TestNginxComplexSubtests/group/TestPods 2025-10-23T21:02:58Z logger.go:66: Running command kubectl...
TestNginxFailDeployment 2025-10-23T21:02:58Z logger.go:66: NAME    READY   UP-TO-DATE...
TestNginxFailService 2025-10-23T21:02:58Z logger.go:66: NAME    TYPE    CLUSTER-IP...
TestNginxComplexSubtests/group/TestPods 2025-10-23T21:02:58Z logger.go:66: NAME    READY   STATUS...

Root Cause Analysis

Looking at modules/logger/parser/parser.go, the issue appears to be in the parseAndStoreTestOutput function around lines 127-131:

case strings.HasPrefix(data, "Test"):
    vals := strings.Split(data, " ")
    testName := vals[0]
    previousTestName = testName
    logWriter.writeLog(logger, testName, data)

This heuristic assumes that:

  1. Lines starting with "Test" belong to the extracted test name
  2. The previousTestName state is reliable for assigning subsequent lines

However, when multiple tests run in parallel and all write to stdout simultaneously, the OS interleaves their output at the byte/line level. The parser sees this interleaved stream as sequential and makes incorrect assumptions about which test "owns" each line.

The stateful tracking via previousTestName compounds this - once the parser assigns a line to the wrong test, subsequent unmarked lines continue rolling up to the incorrect test until another prefixed line resets the state.

Environment

  • Go version: 1.23.2
  • terratest version: latest
  • OS: Linux
  • Test execution: Parallel tests with t.Parallel()

Possible Solutions

The parser could:

  1. Always require test name prefixes (don't rely on previousTestName state)
  2. Validate that continuation lines match the timestamp/pattern of the previous line
  3. Use more robust parsing that accounts for interleaving (e.g., regex matching the full logger.DoLog format)
  4. Document this as a known limitation when using parallel tests

The issue is particularly problematic because terratest's logger explicitly uses stdout to provide immediate feedback (logger.DoLog writes directly to stdout), which is exactly when parallel execution causes interleaving.

Metadata

Metadata

Assignees

Labels

bugSomething isn't working

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions