Skip to content

[DeepNext] Resolve issue #165: Make logging by default on INFO level#171

Closed
pjedlikowskistx wants to merge 1 commit intodevelopfrom
deep_next/issue_165/2025_09_25_10_22_12
Closed

[DeepNext] Resolve issue #165: Make logging by default on INFO level#171
pjedlikowskistx wants to merge 1 commit intodevelopfrom
deep_next/issue_165/2025_09_25_10_22_12

Conversation

@pjedlikowskistx
Copy link
Contributor

This is description for the MR created by DeepNext.

@pjedlikowskistx
Copy link
Contributor Author

🚧 DeepNext status update

🚀 DeepNext is onto it! Hold on...

@pjedlikowskistx
Copy link
Contributor Author

🚧 DeepNext status update

🔴 DeepNext failed on MR #171: 1 validation error for _State
issue_comments
Input should be a valid list [type=list_type, input_value=None, input_type=NoneType]
For further information visit https://errors.pydantic.dev/2.11/v/list_type

@pjedlikowskistx
Copy link
Contributor Author

🚧 DeepNext status update

🚀 DeepNext is onto it! Hold on...

@pjedlikowskistx
Copy link
Contributor Author

🚧 DeepNext status update

🔴 DeepNext app failed for MR #171: 1 validation error for _State
code_context
Input should be a valid dictionary or instance of ExistingCodeContext [type=model_type, input_value=[], input_type=list]
For further information visit https://errors.pydantic.dev/2.11/v/model_type

@pjedlikowskistx
Copy link
Contributor Author

🚧 DeepNext status update

🚀 DeepNext is onto it! Hold on...

@pjedlikowskistx
Copy link
Contributor Author

🚧 DeepNext status update

🔴 DeepNext app failed for MR #171: 1 validation error for _State
code_context
Input should be a valid dictionary or instance of ExistingCodeContext [type=model_type, input_value=[], input_type=list]
For further information visit https://errors.pydantic.dev/2.11/v/model_type

@pjedlikowskistx
Copy link
Contributor Author

🚧 DeepNext status update

🚀 DeepNext is onto it! Hold on...

@pjedlikowskistx
Copy link
Contributor Author

🚧 DeepNext status update

🔴 DeepNext app failed for MR #171: 1 validation error for _State
code_context
Input should be a valid dictionary or instance of ExistingCodeContext [type=model_type, input_value=[], input_type=list]
For further information visit https://errors.pydantic.dev/2.11/v/model_type

@pjedlikowskistx
Copy link
Contributor Author

🚧 DeepNext status update

🚀 DeepNext is onto it! Hold on...

@pjedlikowskistx
Copy link
Contributor Author

🚧 DeepNext status update

🔴 DeepNext app failed for MR #171: 1 validation error for _State
code_context
Input should be a valid dictionary or instance of ExistingCodeContext [type=model_type, input_value=[], input_type=list]
For further information visit https://errors.pydantic.dev/2.11/v/model_type

@pjedlikowskistx
Copy link
Contributor Author

🚧 DeepNext status update

🚀 DeepNext is onto it! Hold on...

@pjedlikowskistx
Copy link
Contributor Author

🚧 DeepNext status update

🔴 DeepNext app failed for MR #171: 1 validation error for _State
code_context
Input should be a valid dictionary or instance of ExistingCodeContext [type=model_type, input_value=[], input_type=list]
For further information visit https://errors.pydantic.dev/2.11/v/model_type

@pjedlikowskistx
Copy link
Contributor Author

🚧 DeepNext status update

🚀 DeepNext is onto it! Hold on...

@pjedlikowskistx
Copy link
Contributor Author

🚧 DeepNext status update

🔴 DeepNext app failed for MR #171: 1 validation error for _State
code_context
Input should be a valid dictionary or instance of ExistingCodeContext [type=model_type, input_value=[], input_type=list]
For further information visit https://errors.pydantic.dev/2.11/v/model_type

@pjedlikowskistx
Copy link
Contributor Author

🚧 DeepNext status update

🚀 DeepNext is onto it! Hold on...

@pjedlikowskistx
Copy link
Contributor Author

🚧 DeepNext status update

Reasoning (for context only)

### Understanding the Task & Approach
The goal is to reduce logging verbosity by setting the default log level to INFO, while
allowing users to override the log level via a LOG_LEVEL environment variable. This
ensures that logs are informative but not overwhelming by default, and provides
flexibility for debugging or production use.

### Project Context & Code Integration
- The main entrypoints for the application are `apps/app/deep_next/app/entrypoint.py`,
`apps/app/deep_next/app/entrypoint_scheduled.py`, and
`libs/core/deep_next/core/entrypoint.py`.
- Loguru is already used for logging throughout the codebase.
- The `.env.example` file documents environment variables and should be updated to
include LOG_LEVEL for discoverability.

### Implementation Considerations & Trade-offs
- **Centralized Logging Configuration:** Logging should be configured as early as
possible in each entrypoint to ensure all logs respect the desired level.
- **Environment Variable Usage:** The LOG_LEVEL environment variable should be read
(defaulting to INFO if not set) and used to configure Loguru.
- **Minimal Invasiveness:** Only the entrypoints need to be updated for global log level
configuration; no need to refactor all logger calls.
- **Documentation:** Updating `.env.example` ensures users are aware of the new
configuration option.

### Final Decision
The solution will update all main entrypoints to configure Loguru's log level based on
LOG_LEVEL (default INFO), and document this in `.env.example`. This approach is simple,
clear, and maintains project conventions.

Action Plan

What do you think about the action plan below?

[
    {
        "title": "Update .env.example to document LOG_LEVEL",
        "description": "Add a commented example of the LOG_LEVEL environment variable to `.env.example`, explaining its purpose and possible values (e.g., DEBUG, INFO, WARNING, ERROR, CRITICAL). This ensures users are aware of the new configuration option.",
        "target_file": "Path(/deep-next/___data/app/repositories/stxnext_deep-next/.env.example)"
    },
    {
        "title": "Configure Loguru log level in core/entrypoint.py",
        "description": "At the very start of `libs/core/deep_next/core/entrypoint.py`, configure Loguru to set the log level based on the LOG_LEVEL environment variable (defaulting to INFO if not set). This ensures all logs in the core pipeline respect the desired verbosity.",
        "target_file": "Path(/deep-next/___data/app/repositories/stxnext_deep-next/libs/core/deep_next/core/entrypoint.py)"
    },
    {
        "title": "Configure Loguru log level in app/entrypoint.py",
        "description": "At the very start of `apps/app/deep_next/app/entrypoint.py`, configure Loguru to set the log level based on the LOG_LEVEL environment variable (defaulting to INFO if not set). This ensures all logs in the app entrypoint respect the desired verbosity.",
        "target_file": "Path(/deep-next/___data/app/repositories/stxnext_deep-next/apps/app/deep_next/app/entrypoint.py)"
    },
    {
        "title": "Configure Loguru log level in app/entrypoint_scheduled.py",
        "description": "At the very start of `apps/app/deep_next/app/entrypoint_scheduled.py`, configure Loguru to set the log level based on the LOG_LEVEL environment variable (defaulting to INFO if not set). This ensures all logs in the scheduled entrypoint respect the desired verbosity.",
        "target_file": "Path(/deep-next/___data/app/repositories/stxnext_deep-next/apps/app/deep_next/app/entrypoint_scheduled.py)"
    }
]

How to respond?

👌 To ACCEPT the action plan, respond with:

@deepnext
OK

✏️ To REQUEST CHANGES to the action plan, talk to DeepNext following the message format:

@deepnext
<message to DeepNext>

🟢 Step finished. Waiting for your response...

⏱️ DeepNext core execution time: 351 seconds.

@pjedlikowskistx
Copy link
Contributor Author

@deepnext
Add documentation to README

@pjedlikowskistx
Copy link
Contributor Author

🚧 DeepNext status update

Reasoning (for context only)

The task is to set the default logging level to INFO and allow overriding it via the
LOG_LEVEL environment variable, with configuration at all main entrypoints. The previous
plan was correct in updating the entrypoints and .env.example, but feedback requires
also documenting LOG_LEVEL in the README. This ensures users are aware of the new
environment variable both in the example .env and in the main documentation. The order
is: update .env.example (so the variable is discoverable for users and referenced in
documentation), update all entrypoints to respect LOG_LEVEL (so the code actually uses
the variable), and finally update the README to document LOG_LEVEL for user awareness.
These steps are independent except that .env.example and code changes should precede
documentation for accuracy.

Action Plan

What do you think about the action plan below?

[
    {
        "title": "Update .env.example to document LOG_LEVEL",
        "description": "Add a commented example of the LOG_LEVEL environment variable to `.env.example`, explaining its purpose and possible values (e.g., DEBUG, INFO, WARNING, ERROR, CRITICAL). This ensures users are aware of the new configuration option.",
        "target_file": "Path(/deep-next/___data/app/repositories/stxnext_deep-next/.env.example)"
    },
    {
        "title": "Configure Loguru log level in core/entrypoint.py",
        "description": "At the very start of `libs/core/deep_next/core/entrypoint.py`, configure Loguru to set the log level based on the LOG_LEVEL environment variable (defaulting to INFO if not set). This ensures all logs in the core pipeline respect the desired verbosity.",
        "target_file": "Path(/deep-next/___data/app/repositories/stxnext_deep-next/libs/core/deep_next/core/entrypoint.py)"
    },
    {
        "title": "Configure Loguru log level in app/entrypoint.py",
        "description": "At the very start of `apps/app/deep_next/app/entrypoint.py`, configure Loguru to set the log level based on the LOG_LEVEL environment variable (defaulting to INFO if not set). This ensures all logs in the app entrypoint respect the desired verbosity.",
        "target_file": "Path(/deep-next/___data/app/repositories/stxnext_deep-next/apps/app/deep_next/app/entrypoint.py)"
    },
    {
        "title": "Configure Loguru log level in app/entrypoint_scheduled.py",
        "description": "At the very start of `apps/app/deep_next/app/entrypoint_scheduled.py`, configure Loguru to set the log level based on the LOG_LEVEL environment variable (defaulting to INFO if not set). This ensures all logs in the scheduled entrypoint respect the desired verbosity.",
        "target_file": "Path(/deep-next/___data/app/repositories/stxnext_deep-next/apps/app/deep_next/app/entrypoint_scheduled.py)"
    },
    {
        "title": "Document LOG_LEVEL in README",
        "description": "Update the README to document the LOG_LEVEL environment variable, its default value (INFO), and how users can override it to control logging verbosity. This ensures users are aware of the new configuration option and how to use it.",
        "target_file": "Path(/deep-next/___data/app/repositories/stxnext_deep-next/README.md)"
    }
]

How to respond?

👌 To ACCEPT the action plan, respond with:

@deepnext
OK

✏️ To REQUEST CHANGES to the action plan, talk to DeepNext following the message format:

@deepnext
<message to DeepNext>

🟢 Step finished. Waiting for your response...

⏱️ DeepNext core execution time: 278 seconds.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant