-
Notifications
You must be signed in to change notification settings - Fork 199
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
Add more cases for std stream logging #3347
Conversation
Previously, stdout/err logs not output if the streams were not set (i.e. defaulting to None) and logged with the entire stream target if set. This PR adds more cases here with case specific logging: if stdout/err is not redirected, that is now logged. If tuple mode is used, the tuple is unpacked and logged as separate fields. If an unknown format is specified an error is logged (but no exception is raised - it is not the job of this code to validate the stdout/err specifications) This PR is in preparation for a new case to be added in an upcoming PR which requires more serious formatting that was not accomodated by the previous implementation.
else: | ||
logger.error(f"{name} for task {tid} has unknown specification: {target!r}") |
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.
If this is an error, should it also raise an exception? Otherwise, it feels more like a warning, no?
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.
It's an error. It should be validated elsewhere and this code path should be unreachable (and so do something more like raise an assertion that this path is "impossible".
"should" in the sense of thats how things could be but aren't. If you get this message, there's a problem and your workflow won't run as you expect. But this log statement is not the place to be validating that user input: prior to this, this code would log at info level whatever garbage you had fed in, and it will continue to log that garbage here in this case.
PR #3347 attempted to do case-based logging of all the different kinds of stdout/err specification. It failed to capture some of the cases involving os.PathLike, and so after PR #3347, those cases would log an ERROR that the specification was unknown. This new behavior is only a new ERROR logging message - PR #3347 did not change other behaviour. This PR also amends a rich test of stdout/err specification types introduced in PR #3363 to check that no ERROR messages are logged during these tests.
PR #3347 attempted to do case-based logging of all the different kinds of stdout/err specification. It failed to capture some of the cases involving os.PathLike, and so after PR #3347, those cases would log an ERROR that the specification was unknown. This new behavior is only a new ERROR logging message - PR #3347 did not change other behaviour. This PR also amends a rich test of stdout/err specification types introduced in PR #3363 to check that no ERROR messages are logged during these tests.
Previously, stdout/err logs no output if the streams were not set (i.e. defaulting to None) and logged with the entire stream target if set.
This PR adds more cases here with case specific logging: if stdout/err is not redirected, that is now logged. If tuple mode is used, the tuple is unpacked and logged as separate fields. If an unknown format is specified an error is logged (but no exception is raised - it is not the job of this code to validate the stdout/err specifications)
This PR is in preparation for a new case to be added in an upcoming PR which requires more serious formatting that was not accomodated by the previous implementation.
Changed Behaviour
log messages - including a new error log
Type of change