feat(confighttp): make the api/logs more elegant

[Yundi339]

Description

I think the log interface returns the full amount every time, which is an unreasonable mechanism.
Of course, I did consider using SSE, but it's not a good fit here. It would just introduce unnecessary complexity and over-engineering. So I tried to do these things.

Logs API improvements:

• Incremental fetch: client sends X-Log-Offset in request header, server returns only new bytes and X-Log-Size in response. Avoids re-sending the full file every 5s.
• HTTP 304 when offset already equals file size (no body).
• Backend cache: re-read log file only when size or mtime changes; use std::atomic<std::shared_ptr> for thread-safe access without locks.
• Pause polling when tab is hidden (Page Visibility API); resume and refresh when visible.
• Handle non-2xx and 304 so failed responses don’t overwrite existing log content.
• Sunshine uses try_incremental_log_read to avoid getting the full logs every time.

============
I know that modifying code related to file operations is an act that is prone to dangerous problems.
Therefore, I suggest that this PR should not be in a hurry to integrate, I will use it locally for a long time to see the stability.

BTW, I added log files to sunshinesvc.cpp on PC, so I could know when Sunshine.exe had a safe and unsafe restart.

Screenshot

Issues Fixed or Closed

Roadmap Issues

Type of Change

• feat: New feature (non-breaking change which adds functionality)
• fix: Bug fix (non-breaking change which fixes an issue)
• docs: Documentation only changes
• style: Changes that do not affect the meaning of the code (white-space, formatting, missing semicolons, etc.)
• refactor: Code change that neither fixes a bug nor adds a feature
• perf: Code change that improves performance
• test: Adding missing tests or correcting existing tests
• build: Changes that affect the build system or external dependencies
• ci: Changes to CI configuration files and scripts
• chore: Other changes that don't modify src or test files
• revert: Reverts a previous commit
• BREAKING CHANGE: Introduces a breaking change (can be combined with any type above)

Checklist

• Code follows the style guidelines of this project
• Code has been self-reviewed
• Code has been commented, particularly in hard-to-understand areas
• Code docstring/documentation-blocks for new or existing methods/components have been added or updated
• Unit tests have been added or updated for any new or modified functionality

AI Usage

• None: No AI tools were used in creating this PR
• Light: AI provided minor assistance (formatting, simple suggestions)
• Moderate: AI helped with code generation or debugging specific parts
• Heavy: AI generated most or all of the code changes

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[Yundi339]

To prevent indefinite memory growth, a setting should be added in the future to limit the buffer size (e.g., 1MB, 10MB, 50MB). This would not affect the local log files. For example, if set to 10MB, the system should only read the trailing 10MB of the file.

[ReenigneArcher]

Thanks for the PRs! For this one specifically, I think I want to get #4645 finished and merged first.

[ReenigneArcher]

@Yundi339 the previously mentioned PR was merged

[LizardByte-bot]

It looks like this PR has been idle for 90 days. If it's still something you're working on or would like to pursue, please leave a comment or update your branch. Otherwise, we'll be closing this PR in 10 days to reduce our backlog. Thanks!

[LizardByte-bot]

This PR was closed because it has been stalled for 10 days with no activity.

[Yundi339]

Description

I think the log interface returns the full amount every time, which is an unreasonable mechanism.
Of course, I did consider using SSE, but it's not a good fit here. It would just introduce unnecessary complexity and over-engineering. So I tried to do these things.

Logs API improvements:

• Incremental fetch: client sends X-Log-Offset in request header, server returns only new bytes and X-Log-Size in response. Avoids re-sending the full file every 5s.
• HTTP 304 when offset already equals file size (no body).
• Backend cache: re-read log file only when size or mtime changes; use std::atomic<std::shared_ptr> for thread-safe access without locks.
• Pause polling when tab is hidden (Page Visibility API); resume and refresh when visible.
• Handle non-2xx and 304 so failed responses don’t overwrite existing log content.
• Sunshine uses try_incremental_log_read to avoid getting the full logs every time.

============
I know that modifying code related to file operations is an act that is prone to dangerous problems.
Therefore, I suggest that this PR should not be in a hurry to integrate, I will use it locally for a long time to see the stability.

BTW, I added log files to sunshinesvc.cpp on PC, so I could know when Sunshine.exe had a safe and unsafe restart.

Screenshot

Issues Fixed or Closed

Roadmap Issues

Type of Change

• feat: New feature (non-breaking change which adds functionality)
• fix: Bug fix (non-breaking change which fixes an issue)
• docs: Documentation only changes
• style: Changes that do not affect the meaning of the code (white-space, formatting, missing semicolons, etc.)
• refactor: Code change that neither fixes a bug nor adds a feature
• perf: Code change that improves performance
• test: Adding missing tests or correcting existing tests
• build: Changes that affect the build system or external dependencies
• ci: Changes to CI configuration files and scripts
• chore: Other changes that don't modify src or test files
• revert: Reverts a previous commit
• BREAKING CHANGE: Introduces a breaking change (can be combined with any type above)

Checklist

• Code follows the style guidelines of this project
• Code has been self-reviewed
• Code has been commented, particularly in hard-to-understand areas
• Code docstring/documentation-blocks for new or existing methods/components have been added or updated
• Unit tests have been added or updated for any new or modified functionality

AI Usage

• None: No AI tools were used in creating this PR
• Light: AI provided minor assistance (formatting, simple suggestions)
• Moderate: AI helped with code generation or debugging specific parts
• Heavy: AI generated most or all of the code changes

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[Yundi339]

To prevent indefinite memory growth, a setting should be added in the future to limit the buffer size (e.g., 1MB, 10MB, 50MB). This would not affect the local log files. For example, if set to 10MB, the system should only read the trailing 10MB of the file.

[ReenigneArcher]

Thanks for the PRs! For this one specifically, I think I want to get #4645 finished and merged first.

[ReenigneArcher]

@Yundi339 the previously mentioned PR was merged

[LizardByte-bot]

It looks like this PR has been idle for 90 days. If it's still something you're working on or would like to pursue, please leave a comment or update your branch. Otherwise, we'll be closing this PR in 10 days to reduce our backlog. Thanks!

[LizardByte-bot]

This PR was closed because it has been stalled for 10 days with no activity.

[Yundi339]

Description

I think the log interface returns the full amount every time, which is an unreasonable mechanism.
Of course, I did consider using SSE, but it's not a good fit here. It would just introduce unnecessary complexity and over-engineering. So I tried to do these things.

Logs API improvements:

• Incremental fetch: client sends X-Log-Offset in request header, server returns only new bytes and X-Log-Size in response. Avoids re-sending the full file every 5s.
• HTTP 304 when offset already equals file size (no body).
• Backend cache: re-read log file only when size or mtime changes; use std::atomic<std::shared_ptr> for thread-safe access without locks.
• Pause polling when tab is hidden (Page Visibility API); resume and refresh when visible.
• Handle non-2xx and 304 so failed responses don’t overwrite existing log content.
• Sunshine uses try_incremental_log_read to avoid getting the full logs every time.

============
I know that modifying code related to file operations is an act that is prone to dangerous problems.
Therefore, I suggest that this PR should not be in a hurry to integrate, I will use it locally for a long time to see the stability.

BTW, I added log files to sunshinesvc.cpp on PC, so I could know when Sunshine.exe had a safe and unsafe restart.

Screenshot

Issues Fixed or Closed

Roadmap Issues

Type of Change

• feat: New feature (non-breaking change which adds functionality)
• fix: Bug fix (non-breaking change which fixes an issue)
• docs: Documentation only changes
• style: Changes that do not affect the meaning of the code (white-space, formatting, missing semicolons, etc.)
• refactor: Code change that neither fixes a bug nor adds a feature
• perf: Code change that improves performance
• test: Adding missing tests or correcting existing tests
• build: Changes that affect the build system or external dependencies
• ci: Changes to CI configuration files and scripts
• chore: Other changes that don't modify src or test files
• revert: Reverts a previous commit
• BREAKING CHANGE: Introduces a breaking change (can be combined with any type above)

Checklist

• Code follows the style guidelines of this project
• Code has been self-reviewed
• Code has been commented, particularly in hard-to-understand areas
• Code docstring/documentation-blocks for new or existing methods/components have been added or updated
• Unit tests have been added or updated for any new or modified functionality

AI Usage

• None: No AI tools were used in creating this PR
• Light: AI provided minor assistance (formatting, simple suggestions)
• Moderate: AI helped with code generation or debugging specific parts
• Heavy: AI generated most or all of the code changes

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[Yundi339]

To prevent indefinite memory growth, a setting should be added in the future to limit the buffer size (e.g., 1MB, 10MB, 50MB). This would not affect the local log files. For example, if set to 10MB, the system should only read the trailing 10MB of the file.

[ReenigneArcher]

Thanks for the PRs! For this one specifically, I think I want to get #4645 finished and merged first.

[ReenigneArcher]

@Yundi339 the previously mentioned PR was merged

[LizardByte-bot]

It looks like this PR has been idle for 90 days. If it's still something you're working on or would like to pursue, please leave a comment or update your branch. Otherwise, we'll be closing this PR in 10 days to reduce our backlog. Thanks!

[LizardByte-bot]

This PR was closed because it has been stalled for 10 days with no activity.

[Yundi339]

Description

I think the log interface returns the full amount every time, which is an unreasonable mechanism.
Of course, I did consider using SSE, but it's not a good fit here. It would just introduce unnecessary complexity and over-engineering. So I tried to do these things.

Logs API improvements:

• Incremental fetch: client sends X-Log-Offset in request header, server returns only new bytes and X-Log-Size in response. Avoids re-sending the full file every 5s.
• HTTP 304 when offset already equals file size (no body).
• Backend cache: re-read log file only when size or mtime changes; use std::atomic<std::shared_ptr> for thread-safe access without locks.
• Pause polling when tab is hidden (Page Visibility API); resume and refresh when visible.
• Handle non-2xx and 304 so failed responses don’t overwrite existing log content.
• Sunshine uses try_incremental_log_read to avoid getting the full logs every time.

============
I know that modifying code related to file operations is an act that is prone to dangerous problems.
Therefore, I suggest that this PR should not be in a hurry to integrate, I will use it locally for a long time to see the stability.

BTW, I added log files to sunshinesvc.cpp on PC, so I could know when Sunshine.exe had a safe and unsafe restart.

Screenshot

Issues Fixed or Closed

Roadmap Issues

Type of Change

• feat: New feature (non-breaking change which adds functionality)
• fix: Bug fix (non-breaking change which fixes an issue)
• docs: Documentation only changes
• style: Changes that do not affect the meaning of the code (white-space, formatting, missing semicolons, etc.)
• refactor: Code change that neither fixes a bug nor adds a feature
• perf: Code change that improves performance
• test: Adding missing tests or correcting existing tests
• build: Changes that affect the build system or external dependencies
• ci: Changes to CI configuration files and scripts
• chore: Other changes that don't modify src or test files
• revert: Reverts a previous commit
• BREAKING CHANGE: Introduces a breaking change (can be combined with any type above)

Checklist

• Code follows the style guidelines of this project
• Code has been self-reviewed
• Code has been commented, particularly in hard-to-understand areas
• Code docstring/documentation-blocks for new or existing methods/components have been added or updated
• Unit tests have been added or updated for any new or modified functionality

AI Usage

• None: No AI tools were used in creating this PR
• Light: AI provided minor assistance (formatting, simple suggestions)
• Moderate: AI helped with code generation or debugging specific parts
• Heavy: AI generated most or all of the code changes

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[Yundi339]

To prevent indefinite memory growth, a setting should be added in the future to limit the buffer size (e.g., 1MB, 10MB, 50MB). This would not affect the local log files. For example, if set to 10MB, the system should only read the trailing 10MB of the file.

[ReenigneArcher]

Thanks for the PRs! For this one specifically, I think I want to get #4645 finished and merged first.

[ReenigneArcher]

@Yundi339 the previously mentioned PR was merged

[LizardByte-bot]

It looks like this PR has been idle for 90 days. If it's still something you're working on or would like to pursue, please leave a comment or update your branch. Otherwise, we'll be closing this PR in 10 days to reduce our backlog. Thanks!

[LizardByte-bot]

This PR was closed because it has been stalled for 10 days with no activity.

[Yundi339]

Description

I think the log interface returns the full amount every time, which is an unreasonable mechanism.
Of course, I did consider using SSE, but it's not a good fit here. It would just introduce unnecessary complexity and over-engineering. So I tried to do these things.

Logs API improvements:

• Incremental fetch: client sends X-Log-Offset in request header, server returns only new bytes and X-Log-Size in response. Avoids re-sending the full file every 5s.
• HTTP 304 when offset already equals file size (no body).
• Backend cache: re-read log file only when size or mtime changes; use std::atomic<std::shared_ptr> for thread-safe access without locks.
• Pause polling when tab is hidden (Page Visibility API); resume and refresh when visible.
• Handle non-2xx and 304 so failed responses don’t overwrite existing log content.
• Sunshine uses try_incremental_log_read to avoid getting the full logs every time.

============
I know that modifying code related to file operations is an act that is prone to dangerous problems.
Therefore, I suggest that this PR should not be in a hurry to integrate, I will use it locally for a long time to see the stability.

BTW, I added log files to sunshinesvc.cpp on PC, so I could know when Sunshine.exe had a safe and unsafe restart.

Screenshot

Issues Fixed or Closed

Roadmap Issues

Type of Change

• feat: New feature (non-breaking change which adds functionality)
• fix: Bug fix (non-breaking change which fixes an issue)
• docs: Documentation only changes
• style: Changes that do not affect the meaning of the code (white-space, formatting, missing semicolons, etc.)
• refactor: Code change that neither fixes a bug nor adds a feature
• perf: Code change that improves performance
• test: Adding missing tests or correcting existing tests
• build: Changes that affect the build system or external dependencies
• ci: Changes to CI configuration files and scripts
• chore: Other changes that don't modify src or test files
• revert: Reverts a previous commit
• BREAKING CHANGE: Introduces a breaking change (can be combined with any type above)

Checklist

• Code follows the style guidelines of this project
• Code has been self-reviewed
• Code has been commented, particularly in hard-to-understand areas
• Code docstring/documentation-blocks for new or existing methods/components have been added or updated
• Unit tests have been added or updated for any new or modified functionality

AI Usage

• None: No AI tools were used in creating this PR
• Light: AI provided minor assistance (formatting, simple suggestions)
• Moderate: AI helped with code generation or debugging specific parts
• Heavy: AI generated most or all of the code changes

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[Yundi339]

To prevent indefinite memory growth, a setting should be added in the future to limit the buffer size (e.g., 1MB, 10MB, 50MB). This would not affect the local log files. For example, if set to 10MB, the system should only read the trailing 10MB of the file.

[ReenigneArcher]

Thanks for the PRs! For this one specifically, I think I want to get #4645 finished and merged first.

[ReenigneArcher]

@Yundi339 the previously mentioned PR was merged

[LizardByte-bot]

It looks like this PR has been idle for 90 days. If it's still something you're working on or would like to pursue, please leave a comment or update your branch. Otherwise, we'll be closing this PR in 10 days to reduce our backlog. Thanks!

[LizardByte-bot]

This PR was closed because it has been stalled for 10 days with no activity.

[Yundi339]

Description

I think the log interface returns the full amount every time, which is an unreasonable mechanism.
Of course, I did consider using SSE, but it's not a good fit here. It would just introduce unnecessary complexity and over-engineering. So I tried to do these things.

Logs API improvements:

• Incremental fetch: client sends X-Log-Offset in request header, server returns only new bytes and X-Log-Size in response. Avoids re-sending the full file every 5s.
• HTTP 304 when offset already equals file size (no body).
• Backend cache: re-read log file only when size or mtime changes; use std::atomic<std::shared_ptr> for thread-safe access without locks.
• Pause polling when tab is hidden (Page Visibility API); resume and refresh when visible.
• Handle non-2xx and 304 so failed responses don’t overwrite existing log content.
• Sunshine uses try_incremental_log_read to avoid getting the full logs every time.

============
I know that modifying code related to file operations is an act that is prone to dangerous problems.
Therefore, I suggest that this PR should not be in a hurry to integrate, I will use it locally for a long time to see the stability.

BTW, I added log files to sunshinesvc.cpp on PC, so I could know when Sunshine.exe had a safe and unsafe restart.

Screenshot

Issues Fixed or Closed

Roadmap Issues

Type of Change

• feat: New feature (non-breaking change which adds functionality)
• fix: Bug fix (non-breaking change which fixes an issue)
• docs: Documentation only changes
• style: Changes that do not affect the meaning of the code (white-space, formatting, missing semicolons, etc.)
• refactor: Code change that neither fixes a bug nor adds a feature
• perf: Code change that improves performance
• test: Adding missing tests or correcting existing tests
• build: Changes that affect the build system or external dependencies
• ci: Changes to CI configuration files and scripts
• chore: Other changes that don't modify src or test files
• revert: Reverts a previous commit
• BREAKING CHANGE: Introduces a breaking change (can be combined with any type above)

Checklist

• Code follows the style guidelines of this project
• Code has been self-reviewed
• Code has been commented, particularly in hard-to-understand areas
• Code docstring/documentation-blocks for new or existing methods/components have been added or updated
• Unit tests have been added or updated for any new or modified functionality

AI Usage

• None: No AI tools were used in creating this PR
• Light: AI provided minor assistance (formatting, simple suggestions)
• Moderate: AI helped with code generation or debugging specific parts
• Heavy: AI generated most or all of the code changes

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[Yundi339]

To prevent indefinite memory growth, a setting should be added in the future to limit the buffer size (e.g., 1MB, 10MB, 50MB). This would not affect the local log files. For example, if set to 10MB, the system should only read the trailing 10MB of the file.

[ReenigneArcher]

Thanks for the PRs! For this one specifically, I think I want to get #4645 finished and merged first.

[ReenigneArcher]

@Yundi339 the previously mentioned PR was merged

[LizardByte-bot]

It looks like this PR has been idle for 90 days. If it's still something you're working on or would like to pursue, please leave a comment or update your branch. Otherwise, we'll be closing this PR in 10 days to reduce our backlog. Thanks!

[LizardByte-bot]

This PR was closed because it has been stalled for 10 days with no activity.

[Yundi339]

Description

I think the log interface returns the full amount every time, which is an unreasonable mechanism.
Of course, I did consider using SSE, but it's not a good fit here. It would just introduce unnecessary complexity and over-engineering. So I tried to do these things.

Logs API improvements:

• Incremental fetch: client sends X-Log-Offset in request header, server returns only new bytes and X-Log-Size in response. Avoids re-sending the full file every 5s.
• HTTP 304 when offset already equals file size (no body).
• Backend cache: re-read log file only when size or mtime changes; use std::atomic<std::shared_ptr> for thread-safe access without locks.
• Pause polling when tab is hidden (Page Visibility API); resume and refresh when visible.
• Handle non-2xx and 304 so failed responses don’t overwrite existing log content.
• Sunshine uses try_incremental_log_read to avoid getting the full logs every time.

============
I know that modifying code related to file operations is an act that is prone to dangerous problems.
Therefore, I suggest that this PR should not be in a hurry to integrate, I will use it locally for a long time to see the stability.

BTW, I added log files to sunshinesvc.cpp on PC, so I could know when Sunshine.exe had a safe and unsafe restart.

Screenshot

Issues Fixed or Closed

Roadmap Issues

Type of Change

• feat: New feature (non-breaking change which adds functionality)
• fix: Bug fix (non-breaking change which fixes an issue)
• docs: Documentation only changes
• style: Changes that do not affect the meaning of the code (white-space, formatting, missing semicolons, etc.)
• refactor: Code change that neither fixes a bug nor adds a feature
• perf: Code change that improves performance
• test: Adding missing tests or correcting existing tests
• build: Changes that affect the build system or external dependencies
• ci: Changes to CI configuration files and scripts
• chore: Other changes that don't modify src or test files
• revert: Reverts a previous commit
• BREAKING CHANGE: Introduces a breaking change (can be combined with any type above)

Checklist

• Code follows the style guidelines of this project
• Code has been self-reviewed
• Code has been commented, particularly in hard-to-understand areas
• Code docstring/documentation-blocks for new or existing methods/components have been added or updated
• Unit tests have been added or updated for any new or modified functionality

AI Usage

• None: No AI tools were used in creating this PR
• Light: AI provided minor assistance (formatting, simple suggestions)
• Moderate: AI helped with code generation or debugging specific parts
• Heavy: AI generated most or all of the code changes

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[Yundi339]

To prevent indefinite memory growth, a setting should be added in the future to limit the buffer size (e.g., 1MB, 10MB, 50MB). This would not affect the local log files. For example, if set to 10MB, the system should only read the trailing 10MB of the file.

[ReenigneArcher]

Thanks for the PRs! For this one specifically, I think I want to get #4645 finished and merged first.

[ReenigneArcher]

@Yundi339 the previously mentioned PR was merged

[LizardByte-bot]

It looks like this PR has been idle for 90 days. If it's still something you're working on or would like to pursue, please leave a comment or update your branch. Otherwise, we'll be closing this PR in 10 days to reduce our backlog. Thanks!

[LizardByte-bot]

This PR was closed because it has been stalled for 10 days with no activity.

[Yundi339]

Description

I think the log interface returns the full amount every time, which is an unreasonable mechanism.
Of course, I did consider using SSE, but it's not a good fit here. It would just introduce unnecessary complexity and over-engineering. So I tried to do these things.

Logs API improvements:

• Incremental fetch: client sends X-Log-Offset in request header, server returns only new bytes and X-Log-Size in response. Avoids re-sending the full file every 5s.
• HTTP 304 when offset already equals file size (no body).
• Backend cache: re-read log file only when size or mtime changes; use std::atomic<std::shared_ptr> for thread-safe access without locks.
• Pause polling when tab is hidden (Page Visibility API); resume and refresh when visible.
• Handle non-2xx and 304 so failed responses don’t overwrite existing log content.
• Sunshine uses try_incremental_log_read to avoid getting the full logs every time.

============
I know that modifying code related to file operations is an act that is prone to dangerous problems.
Therefore, I suggest that this PR should not be in a hurry to integrate, I will use it locally for a long time to see the stability.

BTW, I added log files to sunshinesvc.cpp on PC, so I could know when Sunshine.exe had a safe and unsafe restart.

Screenshot

Issues Fixed or Closed

Roadmap Issues

Type of Change

• feat: New feature (non-breaking change which adds functionality)
• fix: Bug fix (non-breaking change which fixes an issue)
• docs: Documentation only changes
• style: Changes that do not affect the meaning of the code (white-space, formatting, missing semicolons, etc.)
• refactor: Code change that neither fixes a bug nor adds a feature
• perf: Code change that improves performance
• test: Adding missing tests or correcting existing tests
• build: Changes that affect the build system or external dependencies
• ci: Changes to CI configuration files and scripts
• chore: Other changes that don't modify src or test files
• revert: Reverts a previous commit
• BREAKING CHANGE: Introduces a breaking change (can be combined with any type above)

Checklist

• Code follows the style guidelines of this project
• Code has been self-reviewed
• Code has been commented, particularly in hard-to-understand areas
• Code docstring/documentation-blocks for new or existing methods/components have been added or updated
• Unit tests have been added or updated for any new or modified functionality

AI Usage

• None: No AI tools were used in creating this PR
• Light: AI provided minor assistance (formatting, simple suggestions)
• Moderate: AI helped with code generation or debugging specific parts
• Heavy: AI generated most or all of the code changes

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[Yundi339]

To prevent indefinite memory growth, a setting should be added in the future to limit the buffer size (e.g., 1MB, 10MB, 50MB). This would not affect the local log files. For example, if set to 10MB, the system should only read the trailing 10MB of the file.

[ReenigneArcher]

Thanks for the PRs! For this one specifically, I think I want to get #4645 finished and merged first.

[ReenigneArcher]

@Yundi339 the previously mentioned PR was merged

[LizardByte-bot]

It looks like this PR has been idle for 90 days. If it's still something you're working on or would like to pursue, please leave a comment or update your branch. Otherwise, we'll be closing this PR in 10 days to reduce our backlog. Thanks!

[LizardByte-bot]

This PR was closed because it has been stalled for 10 days with no activity.