The error message from template.go:Run() is not logged anywhere, so it's either eaten by the graph handling code above (quickly investigated the call tree and found no opportunity to do so) or the waitForPodCompletion call above does not return any error.

waitForPodCompletion only returns no error when the waitForPodCompletionOrTimeout call above returns retry=false && err == nil.

waitForPodCompletionOrTimeout only returns retry=false && err == nil when (1) pod.Spec.RestartPolicy == Always (we can probably rule out this one) or when one of the two (1, 2) calls to podJobIsOK returns true. Both calls are preceeded by a call to podLogNewFailedContainers. This method is the one that actually emitted the error message about a failing container. Both podJobIsOK and podLogNewFailedContainers iterate over all container statuses and decide (among other things, all of which do not looks suspicious) based on container ExitCode. Because the podLogNew... method emitted the error message about test container, its exit code was not 0 when that method executed. But some podJobIsOK execution that run afterwards is also checking for this condition but did not hit it, which is strange.