Always forward Gator warnings/errors to user regardless of --all-msg flag#27
Always forward Gator warnings/errors to user regardless of --all-msg flag#27EdNutting wants to merge 1 commit intoIntuity:mainfrom
--all-msg flag#27Conversation
…flag When --all-msg is NOT specified, Gator's own warnings and errors (like the command substitution warning) were not being surfaced to the user. This change ensures that WARNING, ERROR, and CRITICAL messages originating from Gator itself are always forwarded to the parent layer, while still respecting the --all-msg flag for filtering verbose output from invoked tools. Key changes: - Modified Logger.log() to forward high-severity messages (WARNING+) from Gator itself regardless of the forward setting - Messages forwarded from child processes are still filtered by --all-msg - Added test_linked_no_forward to verify the new behavior Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
| timestamp = datetime.now() | ||
| # Always forward warnings, errors, and critical messages from Gator itself | ||
| # (not forwarded from children), regardless of forward setting | ||
| should_forward = forward or (not forwarded and severity >= LogSeverity.WARNING) |
There was a problem hiding this comment.
If I've not missed something, won't this only forward gator messages from the first child layer - anything below that would have the forwarded flag set and be lost?
I suspect there would need to be some special marker on messages raising up the stack indicating they were coming from gator's own channel, so that they're always forwarded.
There was a problem hiding this comment.
Ugh yeah...I forgot Gator invokes itself in infinite nesting. I need to ask you about that architecture as I'm not sure I fully get why it needs to do nested invocation rather than just using one Python instance to recurse down the tree of jobs / manage invocations accordingly.
There was a problem hiding this comment.
Maybe I still don't quite get what it's doing - local scheduler invokes itself for nested job groups/arrays (I think). Slurm I'm not quite sure if it's dispatching JobArray/JobGroup to a node of Slurm to be executed or just aggregating locally then dispacting the end Jobs to Slurm??
|
Closing until I fix the nested logging case as you've highlighted. |
2 participants
Problem
By default
--all-msg=False, so Gator's own warnings and errors were not being surfaced to the user. This meant that important messages from Gator itself - such as the new command substitution warning, resource limit violations, or dependency errors - would be silently filtered out along with tool output.This problem was also present with the
--quietflag.Solution
This PR modifies the logger to always forward WARNING, ERROR, and CRITICAL messages that originate from Gator itself to the parent layer, regardless of the
--all-msg/--quietflag setting. Messages forwarded from child processes (tools that Gator invokes) continue to respect the--all-msgflag as expected.Key Changes
gator/common/logger.py: Updated thelog()method to check if a message originates from Gator itself (not forwarded from children) and automatically forward high-severity messages (WARNING+) regardless of theforwardsettingtest_linked_no_forwardintests/common/test_logger.pyto verify that:forward=Falseforward=Falseforwarded=True) are NOT forwarded whenforward=FalseBehaviour After This Change
--quiet--all-msgTesting
forward=FalseImpact
This change ensures that users are always aware of important issues detected by Gator itself, improving visibility and debugging while still maintaining the ability to filter out verbose tool output with the
--quietflag.