Skip to content

Conversation

@willkill07
Copy link
Member

@willkill07 willkill07 commented Oct 8, 2025

Description

User specification of console logging did nothing. The root issue was we had multiple logger handlers. This PR addresses this bug and fixes it via the following:

  • Fixed logging configuration not being applied - Workflow builder now properly manages console handlers to respect configured log levels
  • Added extra="forbid" to GeneralConfig - Invalid configuration fields are now rejected with clear validation errors
  • Ensured workflow results always visible - If console log level is greater than info, print the workflow results. If <= INFO, then log the results
  • Fixed example config structure - Updated simple_auth config to use correct general.telemetry.logging format
  • Improved logging format to have the level come after the time. Also added line number of file/module

Default level:

<snipped for brevity>
...
------------------------------
2025-10-07 21:05:36 - INFO     - nat.agent.rewoo_agent.agent:373 - [AGENT] Completed level 1 with 1 tools
2025-10-07 21:05:37 - INFO     - nat.agent.rewoo_agent.agent:493 - ReWOO agent solver output: 
------------------------------
[AGENT]
Agent input: Make a joke comparing Elon and Mark Zuckerberg's birthdays?
Agent's thoughts: 
Why did Elon Musk and Mark Zuckerberg's birthdays go to therapy? Because Elon's birthday (June 28) was feeling a little "spacey" and Mark's birthday (May 14) was having some "social" anxiety!
------------------------------
2025-10-07 21:05:37 - WARNING  - nat.builder.intermediate_step_manager:94 - Step id a1b24e96-0fdd-4fc5-9a07-a6b3c0699e80 not found in outstanding start steps
2025-10-07 21:05:37 - CRITICAL - nat.front_ends.console.console_front_end_plugin:100 - 
--------------------------------------------------
Workflow Result:
['Why did Elon Musk and Mark Zuckerberg\'s birthdays go to therapy? Because Elon\'s birthday (June 28) was feeling a little "spacey" and Mark\'s birthday (May 14) was having some "social" anxiety!']
--------------------------------------------------

Error level (when set in workflow config):

2025-10-07 21:07:59 - INFO     - nat.cli.commands.start:192 - Starting NAT from config file: 'examples/agents/rewoo/configs/config.yml'

Configuration Summary:
--------------------
Workflow Type: rewoo_agent
Number of Functions: 6
Number of Function Groups: 0
Number of LLMs: 1
Number of Embedders: 0
Number of Memory: 0
Number of Object Stores: 0
Number of Retrievers: 0
Number of TTC Strategies: 0
Number of Authentication Providers: 0

2025-10-07 21:07:11 - CRITICAL - nat.front_ends.console.console_front_end_plugin:100 - 
--------------------------------------------------
Workflow Result:
["Why did Elon Musk and Mark Zuckerberg have different birthday parties? Because Elon's was a 'rocket' success on June 28, while Mark's was a 'social' gathering on May 14! Guess you could say their birthdays were 'launched' on different trajectories!"]
--------------------------------------------------

Error level (when set as envvar):

2025-10-07 21:07:11 - CRITICAL - nat.front_ends.console.console_front_end_plugin:100 - 
--------------------------------------------------
Workflow Result:
["Why did Elon Musk and Mark Zuckerberg have different birthday parties? Because Elon's was a 'rocket' success on June 28, while Mark's was a 'social' gathering on May 14! Guess you could say their birthdays were 'launched' on different trajectories!"]
--------------------------------------------------

By Submitting this PR I confirm:

  • I am familiar with the Contributing Guidelines.
  • We require that all contributors "sign-off" on their commits. This certifies that the contribution is your original work, or you have rights to submit it under the same license, or a compatible license.
    • Any contribution which contains commits that are not Signed-Off will not be accepted.
  • When the PR is ready for review, new or existing tests cover these changes.
  • When the PR is ready for review, the documentation is up to date with these changes.

Summary by CodeRabbit

  • New Features

    • Result messages are now always surfaced (logged at a higher severity) so workflow outputs are visible regardless of INFO-level settings.
  • Refactor

    • Logging settings reorganized under a telemetry namespace while preserving console type and level.
    • Root-level logging management unified to prevent duplicate handlers and restore prior console behavior on exit.
  • Bug Fixes

    • Log formatting standardized to include timestamp, level, logger name and line number.
  • Chores

    • Configuration validation tightened: unknown config fields are rejected.

@willkill07 willkill07 self-assigned this Oct 8, 2025
@willkill07 willkill07 requested a review from a team as a code owner October 8, 2025 00:17
@willkill07 willkill07 added bug Something isn't working non-breaking Non-breaking change labels Oct 8, 2025
@coderabbitai
Copy link

coderabbitai bot commented Oct 8, 2025

Warning

Rate limit exceeded

@willkill07 has exceeded the limit for the number of commits or files that can be reviewed per hour. Please wait 6 minutes and 26 seconds before requesting another review.

⌛ How to resolve this issue?

After the wait time has elapsed, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout.

Please see our FAQ for further information.

📥 Commits

Reviewing files that changed from the base of the PR and between d96f82c and 43b130e.

📒 Files selected for processing (1)
  • src/nat/front_ends/console/console_front_end_plugin.py (1 hunks)

Walkthrough

Rehomes logging config under telemetry; forbids unknown fields in GeneralConfig; adds root-logger handler orchestration to WorkflowBuilder (capture/adjust/remove/restore); standardizes logging formatter and setup; and changes console front-end to log results but fall back to stdout when INFO would be suppressed.

Changes

Cohort / File(s) Summary
Telemetry config relocation
examples/front_ends/simple_auth/src/nat_simple_auth/configs/config.yml
Moves logging keys from general.logging.console.* to telemetry.logging.console.* without changing values.
Config validation hardening
src/nat/data_models/config.py
GeneralConfig.model_config updated from ConfigDict(protected_namespaces=()) to ConfigDict(protected_namespaces=(), extra="forbid"), rejecting unknown fields.
Root logger handler orchestration
src/nat/builder/.../workflow_builder.py
Adds root-level handler management: captures root logger, attaches builder-managed handlers, detects telemetry console config, removes or clamps existing root StreamHandlers (recording prior state in _removed_root_handlers), ensures root level >= min handler level, and restores handlers/levels on exit.
Console front-end output path
src/nat/front_ends/console/console_front_end_plugin.py
Builds a formatted result message; logs via logger.info when handlers allow, otherwise prints to stdout so INFO-level results are visible even if suppressed by root handlers.
Logging formatter & setup changes
src/nat/observability/register.py, src/nat/cli/entrypoint.py
Replaces default handler formatting with explicit Formatter("%(asctime)s - %(levelname)-8s - %(name)s:%(lineno)d - %(message)s", datefmt="%Y-%m-%d %H:%M:%S") and updates setup_logging to pass explicit format/datefmt to basicConfig.

Sequence Diagram(s)

sequenceDiagram
  autonumber
  actor App
  participant WB as WorkflowBuilder
  participant RL as RootLogger
  participant SH as StreamHandlersStore

  App->>WB: __aenter__()
  WB->>RL: fetch root logger & handlers
  WB->>RL: attach builder-managed handlers
  alt telemetry console configured
    WB->>SH: remove non-builder StreamHandlers\n(record in _removed_root_handlers)
  else no telemetry console
    WB->>SH: clamp existing StreamHandler levels\n(record previous levels)
  end
  WB->>RL: set root level >= min handler level

  App->>WB: __aexit__()
  WB->>RL: remove builder-managed handlers
  WB->>SH: restore removed handlers and original levels
Loading
sequenceDiagram
  autonumber
  participant CFE as ConsoleFrontEnd
  participant RL as RootLogger
  participant STD as Stdout

  CFE->>CFE: build result_message (prefix/line/suffix)
  CFE->>RL: evaluate effective handler levels
  alt INFO would be suppressed by root handlers
    CFE->>STD: print(result_message)
  else
    CFE->>RL: logger.info(result_message)
  end
Loading

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

Suggested labels

breaking

Pre-merge checks and finishing touches and finishing touches

❌ Failed checks (1 warning)
Check name Status Explanation Resolution
Docstring Coverage ⚠️ Warning Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. You can run @coderabbitai generate docstrings to improve docstring coverage.
✅ Passed checks (2 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title Check ✅ Passed The title “fix: ensure console logging is configurable” uses an imperative verb, clearly summarizes the main change, and remains concise under the character limit.

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

@coderabbitai coderabbitai bot added the breaking Breaking change label Oct 8, 2025
@willkill07 willkill07 removed the breaking Breaking change label Oct 8, 2025
Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🧹 Nitpick comments (1)
src/nat/builder/workflow_builder.py (1)

196-198: Refactor: Console handler detection relies on fragile class name inspection.

The current approach of checking if "console" is in the class name is brittle and could break with custom handler implementations or naming variations.

Consider one of these more robust approaches:

  1. Use a registration mechanism: Add a method or attribute to logging configs to explicitly declare if they're console handlers
  2. Check handler type more precisely: Examine the handler's stream attribute to see if it's sys.stdout or sys.stderr
  3. Use configuration metadata: Add an explicit is_console_handler flag to logging configs

Example for approach 2:

-        has_console_handler = any(
-            hasattr(config, "__class__") and "console" in config.__class__.__name__.lower()
-            for config in telemetry_config.logging.values())
+        # After handlers are created, check if any write to stdout/stderr
+        has_console_handler = any(
+            isinstance(handler, logging.StreamHandler) and 
+            getattr(handler, 'stream', None) in (sys.stdout, sys.stderr)
+            for handler in self._logging_handlers.values())
📜 Review details

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between a06926e and ae869b6.

📒 Files selected for processing (4)
  • examples/front_ends/simple_auth/src/nat_simple_auth/configs/config.yml (1 hunks)
  • src/nat/builder/workflow_builder.py (4 hunks)
  • src/nat/data_models/config.py (1 hunks)
  • src/nat/front_ends/console/console_front_end_plugin.py (1 hunks)
🧰 Additional context used
📓 Path-based instructions (9)
**/*.{py,yaml,yml}

📄 CodeRabbit inference engine (.cursor/rules/nat-test-llm.mdc)

**/*.{py,yaml,yml}: Configure response_seq as a list of strings; values cycle per call, and [] yields an empty string.
Configure delay_ms to inject per-call artificial latency in milliseconds for nat_test_llm.

Files:

  • src/nat/data_models/config.py
  • examples/front_ends/simple_auth/src/nat_simple_auth/configs/config.yml
  • src/nat/builder/workflow_builder.py
  • src/nat/front_ends/console/console_front_end_plugin.py
**/*.py

📄 CodeRabbit inference engine (.cursor/rules/nat-test-llm.mdc)

**/*.py: Programmatic use: create TestLLMConfig(response_seq=[...], delay_ms=...), add with builder.add_llm("", cfg).
When retrieving the test LLM wrapper, use builder.get_llm(name, wrapper_type=LLMFrameworkEnum.) and call the framework’s method (e.g., ainvoke, achat, call).

**/*.py: In code comments/identifiers use NAT abbreviations as specified: nat for API namespace/CLI, nvidia-nat for package name, NAT for env var prefixes; do not use these abbreviations in documentation
Follow PEP 20 and PEP 8; run yapf with column_limit=120; use 4-space indentation; end files with a single trailing newline
Run ruff check --fix as linter (not formatter) using pyproject.toml config; fix warnings unless explicitly ignored
Respect naming: snake_case for functions/variables, PascalCase for classes, UPPER_CASE for constants
Treat pyright warnings as errors during development
Exception handling: use bare raise to re-raise; log with logger.error() when re-raising to avoid duplicate stack traces; use logger.exception() when catching without re-raising
Provide Google-style docstrings for every public module, class, function, and CLI command; first line concise and ending with a period; surround code entities with backticks
Validate and sanitize all user input, especially in web or CLI interfaces
Prefer httpx with SSL verification enabled by default and follow OWASP Top-10 recommendations
Use async/await for I/O-bound work; profile CPU-heavy paths with cProfile or mprof before optimizing; cache expensive computations with functools.lru_cache or external cache; leverage NumPy vectorized operations when beneficial

Files:

  • src/nat/data_models/config.py
  • src/nat/builder/workflow_builder.py
  • src/nat/front_ends/console/console_front_end_plugin.py
src/**/*.py

📄 CodeRabbit inference engine (.cursor/rules/general.mdc)

All importable Python code must live under src/ (or packages//src/)

Files:

  • src/nat/data_models/config.py
  • src/nat/builder/workflow_builder.py
  • src/nat/front_ends/console/console_front_end_plugin.py
src/nat/**/*

📄 CodeRabbit inference engine (.cursor/rules/general.mdc)

Changes in src/nat should prioritize backward compatibility

Files:

  • src/nat/data_models/config.py
  • src/nat/builder/workflow_builder.py
  • src/nat/front_ends/console/console_front_end_plugin.py

⚙️ CodeRabbit configuration file

This directory contains the core functionality of the toolkit. Changes should prioritize backward compatibility.

Files:

  • src/nat/data_models/config.py
  • src/nat/builder/workflow_builder.py
  • src/nat/front_ends/console/console_front_end_plugin.py
{src/**/*.py,packages/*/src/**/*.py}

📄 CodeRabbit inference engine (.cursor/rules/general.mdc)

All public APIs must have Python 3.11+ type hints on parameters and return values; prefer typing/collections.abc abstractions; use typing.Annotated when useful

Files:

  • src/nat/data_models/config.py
  • src/nat/builder/workflow_builder.py
  • src/nat/front_ends/console/console_front_end_plugin.py
**/*

⚙️ CodeRabbit configuration file

**/*: # Code Review Instructions

  • Ensure the code follows best practices and coding standards. - For Python code, follow
    PEP 20 and
    PEP 8 for style guidelines.
  • Check for security vulnerabilities and potential issues. - Python methods should use type hints for all parameters and return values.
    Example:
    def my_function(param1: int, param2: str) -> bool:
        pass
  • For Python exception handling, ensure proper stack trace preservation:
    • When re-raising exceptions: use bare raise statements to maintain the original stack trace,
      and use logger.error() (not logger.exception()) to avoid duplicate stack trace output.
    • When catching and logging exceptions without re-raising: always use logger.exception()
      to capture the full stack trace information.

Documentation Review Instructions - Verify that documentation and comments are clear and comprehensive. - Verify that the documentation doesn't contain any TODOs, FIXMEs or placeholder text like "lorem ipsum". - Verify that the documentation doesn't contain any offensive or outdated terms. - Verify that documentation and comments are free of spelling mistakes, ensure the documentation doesn't contain any

words listed in the ci/vale/styles/config/vocabularies/nat/reject.txt file, words that might appear to be
spelling mistakes but are listed in the ci/vale/styles/config/vocabularies/nat/accept.txt file are OK.

Misc. - All code (except .mdc files that contain Cursor rules) should be licensed under the Apache License 2.0,

and should contain an Apache License 2.0 header comment at the top of each file.

  • Confirm that copyright years are up-to date whenever a file is changed.

Files:

  • src/nat/data_models/config.py
  • examples/front_ends/simple_auth/src/nat_simple_auth/configs/config.yml
  • src/nat/builder/workflow_builder.py
  • src/nat/front_ends/console/console_front_end_plugin.py
**/*.{yaml,yml}

📄 CodeRabbit inference engine (.cursor/rules/nat-test-llm.mdc)

In workflow/config YAML, set llms.._type: nat_test_llm to stub responses.

Files:

  • examples/front_ends/simple_auth/src/nat_simple_auth/configs/config.yml
**/configs/**

📄 CodeRabbit inference engine (.cursor/rules/general.mdc)

Configuration files consumed by code must be stored next to that code in a configs/ folder

Files:

  • examples/front_ends/simple_auth/src/nat_simple_auth/configs/config.yml
examples/**/*

⚙️ CodeRabbit configuration file

examples/**/*: - This directory contains example code and usage scenarios for the toolkit, at a minimum an example should
contain a README.md or file README.ipynb.

  • If an example contains Python code, it should be placed in a subdirectory named src/ and should
    contain a pyproject.toml file. Optionally, it might also contain scripts in a scripts/ directory.
  • If an example contains YAML files, they should be placed in a subdirectory named configs/. - If an example contains sample data files, they should be placed in a subdirectory named data/, and should
    be checked into git-lfs.

Files:

  • examples/front_ends/simple_auth/src/nat_simple_auth/configs/config.yml
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
  • GitHub Check: CI Pipeline / Check
🔇 Additional comments (5)
src/nat/data_models/config.py (1)

190-190: LGTM! Stricter configuration validation.

Adding extra="forbid" ensures invalid configuration fields are caught early with clear validation errors, preventing silent misconfigurations.

examples/front_ends/simple_auth/src/nat_simple_auth/configs/config.yml (1)

17-21: LGTM! Configuration restructuring aligns with new telemetry namespace.

The logging configuration has been correctly moved under general.telemetry.logging, maintaining the same settings while adhering to the new structure.

src/nat/builder/workflow_builder.py (2)

230-237: Verify the handler level adjustment logic for non-console configurations.

When no console handler is configured, the code adjusts existing StreamHandler levels to min_handler_level (computed from all handlers including new ones). This behavior may not be correct in all scenarios.

For example, if a DEBUG-level file handler is added but no console handler is configured, this would set existing console StreamHandlers to DEBUG level, potentially causing unexpected verbose console output.

Please verify:

  1. Is the intent to synchronize existing console handler levels with the new minimum level?
  2. Should this only apply if the new minimum level is higher (less verbose) than existing levels?
  3. What happens if users explicitly configured their root logger's StreamHandlers to specific levels?

Consider adding tests to verify behavior in these scenarios:

  • Adding file handler at INFO, no console handler, existing console at DEBUG
  • Adding file handler at WARNING, no console handler, existing console at INFO
  • Adding multiple non-console handlers with different levels

249-259: LGTM! Proper cleanup and restoration of logging handlers.

The exit logic correctly:

  1. Removes builder-managed handlers
  2. Restores previously removed/adjusted handlers
  3. Resets handler levels to their original values

The check if handler not in root_logger.handlers prevents duplicate additions if a handler was somehow re-added.

src/nat/front_ends/console/console_front_end_plugin.py (1)

98-110: Fallback print path never duplicates INFO logs
The conditional stdout print only executes when INFO-level logs are suppressed by handler.level > INFO, and otherwise logger.info emits output—both paths are mutually exclusive.

@coderabbitai coderabbitai bot added the breaking Breaking change label Oct 8, 2025
Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

♻️ Duplicate comments (1)
src/nat/builder/workflow_builder.py (1)

216-220: Duplicate: Root logger level logic prevents handlers from receiving messages.

This issue was already flagged in previous reviews. The use of max() on line 220 incorrectly raises the root logger level instead of lowering it to allow messages through. Additionally, computing min_handler_level from all root logger handlers (line 217) instead of only newly added handlers can cause unintended behavior.

Refer to the previous review comment for the detailed explanation and fix.

🧹 Nitpick comments (1)
src/nat/builder/workflow_builder.py (1)

230-237: Reconsider adjusting existing StreamHandler levels.

When no console handler is configured, this code temporarily adjusts existing StreamHandler levels to min_handler_level. While the original levels are restored in __aexit__, this changes console output verbosity during workflow execution in potentially unexpected ways.

Consider this scenario:

  1. User starts with default console handler at WARNING level
  2. User configures only a file handler at INFO level
  3. Console output becomes more verbose (INFO level) during workflow execution
  4. After workflow completes, console returns to WARNING level

This temporary change in console verbosity might be confusing. The fallback print() in console_front_end_plugin.py (lines 109-110) already ensures workflow results are visible when console handlers would suppress them.

Consider simplifying the logic to:

  • If a console handler is configured: remove existing console handlers (current behavior, lines 224-229)
  • If no console handler is configured: leave existing console handlers unchanged and rely on the console frontend fallback for result visibility

This would make the behavior more predictable while still ensuring workflow results are always visible.

📜 Review details

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between ae869b6 and 462398f.

📒 Files selected for processing (2)
  • src/nat/builder/workflow_builder.py (4 hunks)
  • src/nat/front_ends/console/console_front_end_plugin.py (1 hunks)
🧰 Additional context used
📓 Path-based instructions (6)
**/*.{py,yaml,yml}

📄 CodeRabbit inference engine (.cursor/rules/nat-test-llm.mdc)

**/*.{py,yaml,yml}: Configure response_seq as a list of strings; values cycle per call, and [] yields an empty string.
Configure delay_ms to inject per-call artificial latency in milliseconds for nat_test_llm.

Files:

  • src/nat/front_ends/console/console_front_end_plugin.py
  • src/nat/builder/workflow_builder.py
**/*.py

📄 CodeRabbit inference engine (.cursor/rules/nat-test-llm.mdc)

**/*.py: Programmatic use: create TestLLMConfig(response_seq=[...], delay_ms=...), add with builder.add_llm("", cfg).
When retrieving the test LLM wrapper, use builder.get_llm(name, wrapper_type=LLMFrameworkEnum.) and call the framework’s method (e.g., ainvoke, achat, call).

**/*.py: In code comments/identifiers use NAT abbreviations as specified: nat for API namespace/CLI, nvidia-nat for package name, NAT for env var prefixes; do not use these abbreviations in documentation
Follow PEP 20 and PEP 8; run yapf with column_limit=120; use 4-space indentation; end files with a single trailing newline
Run ruff check --fix as linter (not formatter) using pyproject.toml config; fix warnings unless explicitly ignored
Respect naming: snake_case for functions/variables, PascalCase for classes, UPPER_CASE for constants
Treat pyright warnings as errors during development
Exception handling: use bare raise to re-raise; log with logger.error() when re-raising to avoid duplicate stack traces; use logger.exception() when catching without re-raising
Provide Google-style docstrings for every public module, class, function, and CLI command; first line concise and ending with a period; surround code entities with backticks
Validate and sanitize all user input, especially in web or CLI interfaces
Prefer httpx with SSL verification enabled by default and follow OWASP Top-10 recommendations
Use async/await for I/O-bound work; profile CPU-heavy paths with cProfile or mprof before optimizing; cache expensive computations with functools.lru_cache or external cache; leverage NumPy vectorized operations when beneficial

Files:

  • src/nat/front_ends/console/console_front_end_plugin.py
  • src/nat/builder/workflow_builder.py
src/**/*.py

📄 CodeRabbit inference engine (.cursor/rules/general.mdc)

All importable Python code must live under src/ (or packages//src/)

Files:

  • src/nat/front_ends/console/console_front_end_plugin.py
  • src/nat/builder/workflow_builder.py
src/nat/**/*

📄 CodeRabbit inference engine (.cursor/rules/general.mdc)

Changes in src/nat should prioritize backward compatibility

Files:

  • src/nat/front_ends/console/console_front_end_plugin.py
  • src/nat/builder/workflow_builder.py

⚙️ CodeRabbit configuration file

This directory contains the core functionality of the toolkit. Changes should prioritize backward compatibility.

Files:

  • src/nat/front_ends/console/console_front_end_plugin.py
  • src/nat/builder/workflow_builder.py
{src/**/*.py,packages/*/src/**/*.py}

📄 CodeRabbit inference engine (.cursor/rules/general.mdc)

All public APIs must have Python 3.11+ type hints on parameters and return values; prefer typing/collections.abc abstractions; use typing.Annotated when useful

Files:

  • src/nat/front_ends/console/console_front_end_plugin.py
  • src/nat/builder/workflow_builder.py
**/*

⚙️ CodeRabbit configuration file

**/*: # Code Review Instructions

  • Ensure the code follows best practices and coding standards. - For Python code, follow
    PEP 20 and
    PEP 8 for style guidelines.
  • Check for security vulnerabilities and potential issues. - Python methods should use type hints for all parameters and return values.
    Example:
    def my_function(param1: int, param2: str) -> bool:
        pass
  • For Python exception handling, ensure proper stack trace preservation:
    • When re-raising exceptions: use bare raise statements to maintain the original stack trace,
      and use logger.error() (not logger.exception()) to avoid duplicate stack trace output.
    • When catching and logging exceptions without re-raising: always use logger.exception()
      to capture the full stack trace information.

Documentation Review Instructions - Verify that documentation and comments are clear and comprehensive. - Verify that the documentation doesn't contain any TODOs, FIXMEs or placeholder text like "lorem ipsum". - Verify that the documentation doesn't contain any offensive or outdated terms. - Verify that documentation and comments are free of spelling mistakes, ensure the documentation doesn't contain any

words listed in the ci/vale/styles/config/vocabularies/nat/reject.txt file, words that might appear to be
spelling mistakes but are listed in the ci/vale/styles/config/vocabularies/nat/accept.txt file are OK.

Misc. - All code (except .mdc files that contain Cursor rules) should be licensed under the Apache License 2.0,

and should contain an Apache License 2.0 header comment at the top of each file.

  • Confirm that copyright years are up-to date whenever a file is changed.

Files:

  • src/nat/front_ends/console/console_front_end_plugin.py
  • src/nat/builder/workflow_builder.py

@willkill07 willkill07 force-pushed the wkk_fix-console-logging branch from 45ebeb8 to d96f82c Compare October 8, 2025 01:00
@willkill07
Copy link
Member Author

@coderabbitai full review

@coderabbitai
Copy link

coderabbitai bot commented Oct 8, 2025

✅ Actions performed

Full review triggered.

@willkill07 willkill07 removed the breaking Breaking change label Oct 8, 2025
Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 0

♻️ Duplicate comments (1)
src/nat/builder/workflow_builder.py (1)

216-220: Critical: Incorrect operator prevents messages from reaching handlers.

This is a duplicate of the past review comment. Using max() at line 220 sets the root logger level to be MORE restrictive, blocking messages from reaching handlers configured at lower (more verbose) levels.

For example:

  • If a handler is at INFO (20) but root is at WARNING (30)
  • Using max(30, 20) = 30 keeps root at WARNING
  • This blocks INFO messages from reaching the handler

Additionally, line 217 computes min_handler_level from ALL root logger handlers, including pre-existing handlers, which may not be the intended behavior.

Apply this diff to fix the logic:

         if self._logging_handlers:
-            min_handler_level = min((handler.level for handler in root_logger.handlers), default=logging.CRITICAL)
+            min_handler_level = min((handler.level for handler in self._logging_handlers.values()), default=logging.CRITICAL)
 
             # Ensure the root logger level allows messages through
-            root_logger.level = max(root_logger.level, min_handler_level)
+            root_logger.level = min(root_logger.level, min_handler_level)

This ensures:

  1. Only newly added handlers are considered when computing the minimum level
  2. The root logger level is set to be at least as permissive as the most verbose handler
🧹 Nitpick comments (1)
src/nat/builder/workflow_builder.py (1)

191-198: Console detection heuristic is fragile.

The console handler detection relies on inspecting class names for "console", which is fragile and may break if class naming conventions change. However, this is documented as a hack in the comment.

Consider adding a more robust detection mechanism, such as:

  • Adding a handler_type attribute to logging configuration classes
  • Using a registry pattern for handler types
  • Checking if the config class inherits from a specific base class
📜 Review details

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 462398f and d96f82c.

📒 Files selected for processing (6)
  • examples/front_ends/simple_auth/src/nat_simple_auth/configs/config.yml (1 hunks)
  • src/nat/builder/workflow_builder.py (4 hunks)
  • src/nat/cli/entrypoint.py (1 hunks)
  • src/nat/data_models/config.py (1 hunks)
  • src/nat/front_ends/console/console_front_end_plugin.py (1 hunks)
  • src/nat/observability/register.py (2 hunks)
🚧 Files skipped from review as they are similar to previous changes (2)
  • examples/front_ends/simple_auth/src/nat_simple_auth/configs/config.yml
  • src/nat/front_ends/console/console_front_end_plugin.py
🧰 Additional context used
📓 Path-based instructions (6)
**/*.{py,yaml,yml}

📄 CodeRabbit inference engine (.cursor/rules/nat-test-llm.mdc)

**/*.{py,yaml,yml}: Configure response_seq as a list of strings; values cycle per call, and [] yields an empty string.
Configure delay_ms to inject per-call artificial latency in milliseconds for nat_test_llm.

Files:

  • src/nat/observability/register.py
  • src/nat/builder/workflow_builder.py
  • src/nat/cli/entrypoint.py
  • src/nat/data_models/config.py
**/*.py

📄 CodeRabbit inference engine (.cursor/rules/nat-test-llm.mdc)

**/*.py: Programmatic use: create TestLLMConfig(response_seq=[...], delay_ms=...), add with builder.add_llm("", cfg).
When retrieving the test LLM wrapper, use builder.get_llm(name, wrapper_type=LLMFrameworkEnum.) and call the framework’s method (e.g., ainvoke, achat, call).

**/*.py: In code comments/identifiers use NAT abbreviations as specified: nat for API namespace/CLI, nvidia-nat for package name, NAT for env var prefixes; do not use these abbreviations in documentation
Follow PEP 20 and PEP 8; run yapf with column_limit=120; use 4-space indentation; end files with a single trailing newline
Run ruff check --fix as linter (not formatter) using pyproject.toml config; fix warnings unless explicitly ignored
Respect naming: snake_case for functions/variables, PascalCase for classes, UPPER_CASE for constants
Treat pyright warnings as errors during development
Exception handling: use bare raise to re-raise; log with logger.error() when re-raising to avoid duplicate stack traces; use logger.exception() when catching without re-raising
Provide Google-style docstrings for every public module, class, function, and CLI command; first line concise and ending with a period; surround code entities with backticks
Validate and sanitize all user input, especially in web or CLI interfaces
Prefer httpx with SSL verification enabled by default and follow OWASP Top-10 recommendations
Use async/await for I/O-bound work; profile CPU-heavy paths with cProfile or mprof before optimizing; cache expensive computations with functools.lru_cache or external cache; leverage NumPy vectorized operations when beneficial

Files:

  • src/nat/observability/register.py
  • src/nat/builder/workflow_builder.py
  • src/nat/cli/entrypoint.py
  • src/nat/data_models/config.py
src/**/*.py

📄 CodeRabbit inference engine (.cursor/rules/general.mdc)

All importable Python code must live under src/ (or packages//src/)

Files:

  • src/nat/observability/register.py
  • src/nat/builder/workflow_builder.py
  • src/nat/cli/entrypoint.py
  • src/nat/data_models/config.py
src/nat/**/*

📄 CodeRabbit inference engine (.cursor/rules/general.mdc)

Changes in src/nat should prioritize backward compatibility

Files:

  • src/nat/observability/register.py
  • src/nat/builder/workflow_builder.py
  • src/nat/cli/entrypoint.py
  • src/nat/data_models/config.py

⚙️ CodeRabbit configuration file

This directory contains the core functionality of the toolkit. Changes should prioritize backward compatibility.

Files:

  • src/nat/observability/register.py
  • src/nat/builder/workflow_builder.py
  • src/nat/cli/entrypoint.py
  • src/nat/data_models/config.py
{src/**/*.py,packages/*/src/**/*.py}

📄 CodeRabbit inference engine (.cursor/rules/general.mdc)

All public APIs must have Python 3.11+ type hints on parameters and return values; prefer typing/collections.abc abstractions; use typing.Annotated when useful

Files:

  • src/nat/observability/register.py
  • src/nat/builder/workflow_builder.py
  • src/nat/cli/entrypoint.py
  • src/nat/data_models/config.py
**/*

⚙️ CodeRabbit configuration file

**/*: # Code Review Instructions

  • Ensure the code follows best practices and coding standards. - For Python code, follow
    PEP 20 and
    PEP 8 for style guidelines.
  • Check for security vulnerabilities and potential issues. - Python methods should use type hints for all parameters and return values.
    Example:
    def my_function(param1: int, param2: str) -> bool:
        pass
  • For Python exception handling, ensure proper stack trace preservation:
    • When re-raising exceptions: use bare raise statements to maintain the original stack trace,
      and use logger.error() (not logger.exception()) to avoid duplicate stack trace output.
    • When catching and logging exceptions without re-raising: always use logger.exception()
      to capture the full stack trace information.

Documentation Review Instructions - Verify that documentation and comments are clear and comprehensive. - Verify that the documentation doesn't contain any TODOs, FIXMEs or placeholder text like "lorem ipsum". - Verify that the documentation doesn't contain any offensive or outdated terms. - Verify that documentation and comments are free of spelling mistakes, ensure the documentation doesn't contain any

words listed in the ci/vale/styles/config/vocabularies/nat/reject.txt file, words that might appear to be
spelling mistakes but are listed in the ci/vale/styles/config/vocabularies/nat/accept.txt file are OK.

Misc. - All code (except .mdc files that contain Cursor rules) should be licensed under the Apache License 2.0,

and should contain an Apache License 2.0 header comment at the top of each file.

  • Confirm that copyright years are up-to date whenever a file is changed.

Files:

  • src/nat/observability/register.py
  • src/nat/builder/workflow_builder.py
  • src/nat/cli/entrypoint.py
  • src/nat/data_models/config.py
🔇 Additional comments (7)
src/nat/data_models/config.py (1)

190-190: LGTM! Validation tightening aligns with PR objectives.

Adding extra="forbid" ensures that invalid configuration fields are rejected with clear validation errors, consistent with the existing Config class configuration at line 245.

src/nat/cli/entrypoint.py (1)

55-59: LGTM! Explicit logging format improves consistency.

The multi-argument basicConfig call explicitly defines the log format and date format, ensuring consistent logging presentation across the CLI. This aligns with the formatter changes in src/nat/observability/register.py.

src/nat/observability/register.py (2)

80-87: LGTM! Consistent formatter application.

The formatter ensures that console logs match the standardized format defined in the CLI entrypoint, providing a consistent logging experience across different output handlers.


106-113: LGTM! Consistent formatter application.

The formatter ensures that file logs match the standardized format defined in the CLI entrypoint, maintaining consistency across console and file logging outputs.

src/nat/builder/workflow_builder.py (3)

159-159: LGTM! Tracking removed handlers for restoration.

Initializing _removed_root_handlers as a list of tuples enables proper restoration of handler states during cleanup.


249-260: LGTM! Proper cleanup of logging handlers.

The cleanup logic correctly:

  1. Removes builder-managed handlers from the root logger
  2. Restores previously removed handlers with their original levels
  3. Ensures the logging state is restored to its pre-entry condition

222-237: Root logger handler management verified
Search for addHandler calls found only the WorkflowBuilder attaching and restoring StreamHandlers, so removing or adjusting untracked handlers won’t impact other components.

@coderabbitai coderabbitai bot added the breaking Breaking change label Oct 8, 2025
@willkill07 willkill07 force-pushed the wkk_fix-console-logging branch from ce27cdc to 98275a6 Compare October 8, 2025 13:01
@willkill07 willkill07 force-pushed the wkk_fix-console-logging branch from 98275a6 to 43b130e Compare October 8, 2025 13:05
@willkill07 willkill07 removed the breaking Breaking change label Oct 8, 2025
@willkill07
Copy link
Member Author

/merge

@rapids-bot rapids-bot bot merged commit 9743bcf into NVIDIA:release/1.3 Oct 8, 2025
17 checks passed
dagardner-nv added a commit to dagardner-nv/NeMo-Agent-Toolkit that referenced this pull request Oct 9, 2025
dagardner-nv added a commit to dagardner-nv/NeMo-Agent-Toolkit that referenced this pull request Oct 9, 2025
… profiler agent example"

This reverts commit 2ecef88.

Signed-off-by: David Gardner <[email protected]>
@willkill07 willkill07 deleted the wkk_fix-console-logging branch October 23, 2025 18:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug Something isn't working non-breaking Non-breaking change

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants