-
Notifications
You must be signed in to change notification settings - Fork 36
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fixed the run output log files to be populated when debug=true #53
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the contribution! I left some comments that need to address. Also, can you rename the PR subject to a one-line summary of the change? The subject will be part of the commit history once the PR is merged.
venv.go
Outdated
} | ||
}(stream) | ||
*o = fmt.Sprint(buff.String()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This step could have concurrency issue and race condition with line 248,249 when the main routine dumps the streams into the output strings.
Have you considered https://pkg.go.dev/io#TeeReader? It might need some plumbing to get it work, but using a buffer to collect output is probably much safer than dealing with strings in a multithread context.
In fact, if I had time, I would consider making CommandOutput.Stderr
and CommandOutput.Stdout
buffers, so we can write to the output files once a while to avoid empty log files when ansible puller crashed, but this would be for future.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The real issue is on the string write part on CommandOutput.Stderr and outString. So in the modified implementation, the concurrency issue still exists. Sorry that my original comment on the streamOutput
function was a bit misleading.
Actually, reading this part of code more closely, I realize the previous statement about race condition isn't correct. This part actually branches and ends when c.StreamOutput
is set, so CommandOutput.Stderr
and CommandOutput.Stdout
won't be touched by two routines. Sorry for the confusion here caused by the bad readability of the legacy code.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is a minor point about ignoring the errors returned by cmd.StdoutPipe()
and cmd.StderrPipe()
, but this is an existing issue in the code, and I'm fine with leaving it out of the scope of this PR.
…put to stdout and the CommandOutput struct
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me. Once we address the two nits I left, I will merge this PR. Thanks again for the contribution!
Issue with the logs being output to file when debug flag is set to true.
When the debug=true the StreamOuput code block only streams the output to STDOUT and fails to populate the stdout and stderr field.