Closed mjameswh closed 2 months ago
Hrmm, not much Go binary documentation out there on this issue. Can you confirm that this panics for every Go binary that uses os.Stdout.Write([]byte("foo"))
in this situation? I am not aware of any Go binaries that account for missing descriptors as opposed to just ones forwarded to /dev/null (can check kubectl, cockroachdb, etc, etc). I think the issue is the absence of the descriptor not how the CLI reacts to it.
Stdout.Write
returns an error. Printer
does panic
on that error.
package main
import (
"os"
)
func main() {
_, err := os.Stdout.Write([]byte("foo"))
if err != nil {
panic(err)
}
}
when I run that, I get:
$ go run test.go >&-
panic: write /dev/stdout: bad file descriptor
goroutine 1 [running]:
main.main()
/Users/jwatkins/Development/Temporal/CLI/cli/test.go:10 +0x64
exit status 2
:+1: I wonder if we can find it out before attempting our first write
Describe the bug
Since 0.12.0, launching the CLI without a
stdout
file descriptor causes thePrinter
to panic as soon as the process attempts to emit some output.This notably happens when starting a dev server using TS SDK's
TestWorkflowEnvironment.createLocal()
, due to Node's settingFD_CLOEXEC
on all of its standard file descriptors. This has been recently fixed on the TS SDK (to be included in upcoming v1.9.4), but previous releases will be unusable with CLI 0.12+ until we fix this on CLI side.Minimal Reproduction
This can be easily tested using Bash or a similar shell, with any command:
Note that the
>&-
shell redirection operator at the end of the command instructs the shell to close the STDOUT file descriptor before executing the child process.There is no error if the same command is run without the
>&-
shell redirection operator, or when using previous versions of the CLI with the redirection operator.