Skip to content
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

Fix log follow mode without range header #5347

Merged
merged 3 commits into from
Oct 11, 2024
Merged

Fix log follow mode without range header #5347

merged 3 commits into from
Oct 11, 2024

Conversation

agners
Copy link
Member

@agners agners commented Oct 11, 2024

Proposed change

When using a range with an explicit num_entries systemd-journal-gatewayd will not contiue even when the follow parameter is passed.

Fixes an issue introduced with #5334.

Type of change

  • Dependency upgrade
  • Bugfix (non-breaking change which fixes an issue)
  • New feature (which adds functionality to the supervisor)
  • Breaking change (fix/feature causing existing functionality to break)
  • Code quality improvements to existing code or addition of tests

Additional information

  • This PR fixes or closes issue: fixes #
  • This PR is related to issue:
  • Link to documentation pull request:
  • Link to cli pull request:
  • Link to client library pull request:

Checklist

  • The code change is tested and works locally.
  • Local tests pass. Your PR cannot be merged unless tests pass
  • There is no commented out code in this PR.
  • I have followed the development checklist
  • The code has been formatted using Ruff (ruff format supervisor tests)
  • Tests have been added to verify that the new code works.

If API endpoints or add-on configuration are added/changed:

Summary by CodeRabbit

  • New Features

    • Enhanced log retrieval functionality to support continuous streaming based on the follow parameter.
  • Bug Fixes

    • Adjusted the log fetching behavior to ensure correct range specification for follow requests in the logging API.
  • Tests

    • Introduced new constants for testing log retrieval and updated relevant tests accordingly.

Copy link

coderabbitai bot commented Oct 11, 2024

📝 Walkthrough

Walkthrough

The changes in this pull request focus on the advanced_logs_handler method within the APIHost class in supervisor/api/host.py. The modifications adjust the construction of the range_header based on the follow parameter, allowing for a dynamic response in log retrieval. If follow is True, the range end is set to an empty string, enabling a continuous log stream. If follow is False, it retains the previous behavior of specifying a fixed number of log entries. Similar adjustments were made for default cases when no RANGE header is provided.

Changes

File Change Summary
supervisor/api/host.py Modified advanced_logs_handler to adjust range_header based on follow parameter for dynamic log retrieval. Changes made to both the case with and without RANGE header.
tests/api/test_host.py Introduced DEFAULT_RANGE_FOLLOW constant for follow requests in test_advanced_logs, replacing previous DEFAULT_RANGE. Minor formatting adjustments made.
tests/api/init.py Added DEFAULT_LOG_RANGE_FOLLOW constant for log following in API calls, updating relevant assertions.

Sequence Diagram(s)

sequenceDiagram
    participant Client
    participant APIHost

    Client->>APIHost: Request logs with follow=true
    APIHost-->>Client: Stream logs (range_header: entries=:-{lines-1}:)

    Client->>APIHost: Request logs with follow=false
    APIHost-->>Client: Return fixed number of logs (range_header: entries=:-{lines-1}:{lines})
Loading

📜 Recent review details

Configuration used: CodeRabbit UI
Review profile: CHILL

📥 Commits

Files that changed from the base of the PR and between b65d363 and 2cc8351.

📒 Files selected for processing (1)
  • tests/api/init.py (3 hunks)
🧰 Additional context used
🔇 Additional comments (4)
tests/api/__init__.py (4)

10-10: LGTM: New constant for log following

The addition of DEFAULT_LOG_RANGE_FOLLOW is appropriate for handling log follow mode. Its value correctly omits the end range, allowing for continuous log streaming.


38-38: Correct implementation for log follow mode

The use of DEFAULT_LOG_RANGE_FOLLOW for the /logs/follow endpoint is correct. This change addresses the PR's main objective by allowing continuous log streaming in follow mode.


66-66: Consistent implementation for boot logs follow mode

The use of DEFAULT_LOG_RANGE_FOLLOW for the /logs/boots/0/follow endpoint is correct and consistent with the previous change. This ensures that the fix for log follow mode is applied uniformly across different log types.


Line range hint 10-66: Summary: Comprehensive fix for log follow mode in tests

The changes in this file effectively address the PR's objective of fixing log follow mode. The new constant DEFAULT_LOG_RANGE_FOLLOW is appropriately defined and consistently applied to both regular and boot log follow modes. These modifications ensure that the tests accurately reflect the expected behavior of continuous log streaming in follow mode.

To further validate these changes:

This script will help ensure that all relevant parts of the codebase have been updated consistently with the new log follow mode behavior.

✅ Verification successful

Consistency of DEFAULT_LOG_RANGE_FOLLOW Verified

All instances of DEFAULT_LOG_RANGE_FOLLOW are correctly defined and used within tests/api/__init__.py. No remaining uses of DEFAULT_LOG_RANGE in follow mode contexts were found elsewhere in the codebase.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Verify that the new constant is used consistently across the codebase

# Check for any remaining uses of DEFAULT_LOG_RANGE in follow mode contexts
echo "Checking for potential missed updates to follow mode:"
rg "DEFAULT_LOG_RANGE.*follow" --type python

# Check for any uses of the new DEFAULT_LOG_RANGE_FOLLOW constant
echo "Checking uses of the new DEFAULT_LOG_RANGE_FOLLOW constant:"
rg "DEFAULT_LOG_RANGE_FOLLOW" --type python

Length of output: 398


Script:

#!/bin/bash
# Verify that the new constant is used consistently across the codebase

# Check for any remaining uses of DEFAULT_LOG_RANGE in follow mode contexts
echo "Checking for potential missed updates to follow mode:"
rg "DEFAULT_LOG_RANGE.*follow"

# Check for any uses of the new DEFAULT_LOG_RANGE_FOLLOW constant
echo "Checking uses of the new DEFAULT_LOG_RANGE_FOLLOW constant:"
rg "DEFAULT_LOG_RANGE_FOLLOW"

Length of output: 511


Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media?

❤️ Share
🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

  • Review comments: Directly reply to a review comment made by CodeRabbit. Example:
    • I pushed a fix in commit <commit_id>, please review it.
    • Generate unit testing code for this file.
    • Open a follow-up GitHub issue for this discussion.
  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
    • @coderabbitai generate unit testing code for this file.
    • @coderabbitai modularize this function.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
    • @coderabbitai read src/utils.ts and generate unit testing code.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
    • @coderabbitai help me debug CodeRabbit configuration file.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (Invoked using PR comments)

  • @coderabbitai pause to pause the reviews on a PR.
  • @coderabbitai resume to resume the paused reviews.
  • @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
  • @coderabbitai full review to do a full review from scratch and review all the files again.
  • @coderabbitai summary to regenerate the summary of the PR.
  • @coderabbitai resolve resolve all the CodeRabbit review comments.
  • @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
  • @coderabbitai help to get help.

Other keywords and placeholders

  • Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
  • Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
  • Add @coderabbitai or @coderabbitai title anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (.coderabbit.yaml)

  • You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
  • Please see the configuration documentation for more information.
  • If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

  • Visit our Documentation for detailed information on how to use CodeRabbit.
  • Join our Discord Community to get help, request features, and share feedback.
  • Follow us on X/Twitter for updates and announcements.

@agners agners force-pushed the fix-log-follow-mode branch 2 times, most recently from b41a3e0 to 308ac4e Compare October 11, 2024 10:56
When using a range with an explicit num_entries systemd-journal-gatewayd
will not contiue even when the follow parameter is passed.

Fixes an issue introduced with #5334.
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

🧹 Outside diff range and nitpick comments (2)
supervisor/api/host.py (1)

242-248: LGTM: Improved range_header construction

The changes effectively address the issue with the log follow mode. The range_header construction now correctly handles the follow parameter, allowing for continuous log streaming when follow is True. Additionally, setting a minimum of two lines prevents potential edge cases with single-line responses.

For improved readability, consider extracting the range_header construction into a separate method. This would make the code more maintainable and easier to understand.

Here's a suggested refactor:

def _construct_range_header(self, lines: int, follow: bool) -> str:
    entries = f":-{lines - 1}:"
    num_entries = "" if follow else str(lines)
    return f"entries={entries}{num_entries}"

# In the method body:
range_header = self._construct_range_header(lines, follow)

This refactoring would make the logic more explicit and easier to maintain.

tests/api/test_host.py (1)

Line range hint 1-453: Overall assessment: Changes are focused and effective

The modifications in this file are minimal but crucial for addressing the issue with the log follow mode. The addition of the DEFAULT_RANGE_FOLLOW constant and its usage in the test_advanced_logs function directly support the PR's objective. These changes ensure that the new behavior is properly tested without affecting other test cases.

To further improve confidence in these changes:

  1. Consider adding a new test case that specifically verifies the behavior of the log follow mode with and without a range header.
  2. Ensure that the corresponding changes in the actual implementation (likely in supervisor/api/host.py) align with these test modifications.

Would you like me to outline a potential new test case for the log follow mode?

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL

📥 Commits

Files that changed from the base of the PR and between 308ac4e and b65d363.

📒 Files selected for processing (2)
  • supervisor/api/host.py (1 hunks)
  • tests/api/test_host.py (2 hunks)
🧰 Additional context used
🔇 Additional comments (5)
supervisor/api/host.py (3)

Line range hint 1-1: LGTM: Improved type hinting

The addition of the return type annotation -> web.StreamResponse enhances code readability and provides better type information for the advanced_logs method.


Line range hint 231-241: LGTM: Improved handling of lines parameter

The changes to ensure a minimum of two lines when processing the lines parameter is a good defensive programming practice. It prevents potential issues with single-line responses and edge cases.

The added comment provides a clear explanation for the reasoning behind this change, which is helpful for future maintainers.


Line range hint 1-268: Overall assessment: PR objectives achieved

This PR successfully addresses the issue with the log follow mode without range header. The changes in the advanced_logs_handler method effectively allow for continuous log streaming when the follow parameter is True, while maintaining the previous behavior for non-follow requests.

Key improvements:

  1. The range_header construction now correctly handles the follow parameter.
  2. A minimum of two lines is ensured when processing the lines parameter, preventing potential edge cases.
  3. The code is well-documented with clear comments explaining the reasoning behind the changes.

These changes align well with the PR objectives and should resolve the issue introduced by the previous change (#5333). The implementation is solid, with only minor suggestions for refactoring to improve readability.

tests/api/test_host.py (2)

18-18: LGTM: New constant for follow mode range header

The addition of DEFAULT_RANGE_FOLLOW constant is appropriate. It defines a range header specifically for the log follow mode, which aligns with the PR's objective of fixing the log follow mode without a range header.


237-237: LGTM: Updated test case for log follow mode

The change from DEFAULT_RANGE to DEFAULT_RANGE_FOLLOW in the assertion is correct and necessary. This update ensures that the test case accurately verifies the behavior of the log follow mode with the new range header format. The modification aligns perfectly with the PR's objective of fixing the log follow mode.

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

🧹 Outside diff range and nitpick comments (1)
supervisor/api/host.py (1)

242-242: LGTM! Consider a minor improvement for consistency.

The changes effectively address the issue with the log follow mode when using a range with an explicit num_entries. The modifications allow for continuous log streaming when follow is True, while preserving the original behavior for non-follow mode.

For consistency, consider using parentheses for the ternary operation on line 242, similar to the multi-line format used in lines 246-248. This would improve readability and maintain a consistent style:

range_header = f"entries=:-{lines-1}:{''.format() if follow else lines}"

Also applies to: 246-248

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL

📥 Commits

Files that changed from the base of the PR and between 308ac4e and b65d363.

📒 Files selected for processing (2)
  • supervisor/api/host.py (1 hunks)
  • tests/api/test_host.py (2 hunks)
🧰 Additional context used
🔇 Additional comments (4)
supervisor/api/host.py (1)

242-242: Verify the impact on log retrieval functionality.

The changes effectively address the issue with the log follow mode. The modifications are minimal and focused, which reduces the risk of unintended side effects. However, it's important to verify that these changes don't negatively impact other log retrieval scenarios.

Please run the following tests to ensure the changes work as expected:

  1. Test log retrieval with follow mode enabled:

  2. Test log retrieval with a specific number of lines:

  3. Test log retrieval with both follow mode and a specific number of lines:

Ensure that each scenario behaves correctly, particularly that the follow mode continues to stream logs and that specifying a number of lines returns the expected amount of data.

Also applies to: 246-248

tests/api/test_host.py (3)

18-18: LGTM: New constant for follow mode range.

The addition of DEFAULT_RANGE_FOLLOW constant is appropriate for distinguishing between regular and follow mode ranges in the tests. This aligns with the PR objective to fix the log follow mode.


237-237: LGTM: Updated test for follow mode.

The use of DEFAULT_RANGE_FOLLOW in the test_advanced_logs function for the /host/logs/follow endpoint is correct. This change ensures that the test accurately reflects the expected behavior of the follow mode in the API.


18-18: Overall assessment: Changes are focused and effective.

The modifications in this file are well-aligned with the PR objective to fix the log follow mode without a range header. The addition of the DEFAULT_RANGE_FOLLOW constant and its usage in the test_advanced_logs function improve the accuracy of testing the follow mode functionality without introducing any breaking changes to existing tests.

Also applies to: 237-237

@frenck frenck merged commit e2ada42 into main Oct 11, 2024
20 checks passed
@frenck frenck deleted the fix-log-follow-mode branch October 11, 2024 17:54
@github-actions github-actions bot locked and limited conversation to collaborators Oct 14, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants