Open bcmills opened 4 years ago
CC @golang/osp-team
I understand this issue is related to but not the same as #38751. The difference here is that it happens specifically for subprocess output even when the output is not large. Is that right?
Correct. And the fix here is probably independent of that fix. (Probably os/exec
should be patched to strip out timestamp headers from stdout
and stderr
? But maybe there's a better approach, like suppressing the timestamping entirely in subprocesses.)
The fundamental issue here is that stdout/stderr of faketime binaries is simply not meant to be generally consumable. Rather it is intended only for handling by the playground itself.
I don't think have os/exec
strip headers would be a robust fix, as intermediate processes could still get confused. e.g., exec a bash script, which exec's the original binary and parses its output. In this case, the stdout/stderr is never passing through os/exec
, so it doesn't get a chance to fix it up.
A more robust solution that comes to mind would be to only enable faketime headers if a specific environment variable is set. The playground would always set this variable, and the faketime binary should probably clear it on init so it isn't inherited by os/exec
calls.
At a higher level, I think we need to step back and think about whether we really want to support subprocesses on the playground. The sandbox can support it just fine, but I think these kinds of weird issues are going to keep coming up as long as we have faketime. If we don't support it, we could disable os/exec
entirely. (Users could still directly invoke the syscalls, but we have no support there).
Personally, I think enabling faketime
by an environment variable, clearing that environment variable early during process-init, and allowing os/exec
in general is probably the way to go. I would hate to drop os/exec
entirely in the Playground, given that the sandbox can handle it.
What did you do?
https://play.golang.org/p/Gi7BzeGhs6Q
What did you expect to see?
Similar output to
go test -v
when running the test locally:What did you see instead?
Mangled output containing faketime headers: