Bug: Logfile view floods the console with errors on empty log file

[cdprete]

Spring Boot Admin Server information

• Version: 4.0.4

• Spring Boot version: 4.0.5

• Configured Security: None

• Webflux or Servlet application: WebFlux

Client information

• Spring Boot versions: 4.0.4

• Used discovery mechanism: SBA client (sample apps)

• Webflux or Servlet application: Both

Description

Hello.

I'm opening this ticket since I got no reply in #5272 (comment) on how to proceed. :)

When the log file that should be displayed in the logview is empty, the latter starts to flood the console with errors like

instance.ts:415 GET http://localhost:8080/instances/a973ff14be49/actuator/logfile 416 (Range Not Satisfiable)

Ideally these errors should be ignored or, if wanted, printed at a lower log level (debug, trace or so).

[MohammedGhallab]

I would like to work on this issue

Hello Spring Boot Admin team,

I've noticed this issue where the console gets flooded with 416 Range Not Satisfiable errors when the log file is empty. I've experienced similar issues with log streaming in Spring Boot environments and would like to help resolve this.

Proposed Approach:

1. I will investigate instance.ts and the log-view component to identify the polling logic.
2. I plan to implement a check to gracefully handle the 416 status code, perhaps by pausing the poll or increasing the interval when the file is empty, instead of letting it error out continuously.
3. I'll ensure the fix aligns with the WebFlux/Reactive nature of the SBA server.

As a contributor to the core Spring Boot repository and a Full-stack developer, I'm comfortable navigating the SBA codebase.

May I be assigned to this issue?

Best regards,
Mohammed Ghallab

[cdprete]

I would like to work on this issue

Hello Spring Boot Admin team,

I've noticed this issue where the console gets flooded with 416 Range Not Satisfiable errors when the log file is empty. I've experienced similar issues with log streaming in Spring Boot environments and would like to help resolve this.

Proposed Approach:

1. I will investigate instance.ts and the log-view component to identify the polling logic.
2. I plan to implement a check to gracefully handle the 416 status code, perhaps by pausing the poll or increasing the interval when the file is empty, instead of letting it error out continuously.
3. I'll ensure the fix aligns with the WebFlux/Reactive nature of the SBA server.

As a contributor to the core Spring Boot repository and a Full-stack developer, I'm comfortable navigating the SBA codebase.

May I be assigned to this issue?

Best regards, Mohammed Ghallab

Hello @MohammedGhallab.

Just some inputs from my side:

1. the issue is located in the logtail.ts utility function
2. that's a good idea, from one side, but it should not then introduce a potentially infinite delay
3. there is nothing to be touched on the server side since it's just calling https://docs.spring.io/spring-boot/api/rest/actuator/logfile.html in the end

[MohammedGhallab]

I would like to work on this issue

Hello Spring Boot Admin team,
I've noticed this issue where the console gets flooded with 416 Range Not Satisfiable errors when the log file is empty. I've experienced similar issues with log streaming in Spring Boot environments and would like to help resolve this.
Proposed Approach:

1. I will investigate instance.ts and the log-view component to identify the polling logic.
2. I plan to implement a check to gracefully handle the 416 status code, perhaps by pausing the poll or increasing the interval when the file is empty, instead of letting it error out continuously.
3. I'll ensure the fix aligns with the WebFlux/Reactive nature of the SBA server.

As a contributor to the core Spring Boot repository and a Full-stack developer, I'm comfortable navigating the SBA codebase.
May I be assigned to this issue?
Best regards, Mohammed Ghallab

Hello @MohammedGhallab.

Just some inputs from my side:

1. the issue is located in the logtail.ts utility function
2. that's a good idea, from one side, but it should not then introduce a potentially infinite delay
3. there is nothing to be touched on the server side since it's just calling https://docs.spring.io/spring-boot/api/rest/actuator/logfile.html in the end

Thank you for the quick feedback and for pointing me to logtail.ts; that definitely narrows it down.

I understand your points:

• I will focus the fix within the logtail.ts utility.
• Regarding the polling: I’ll make sure the logic handles the 416 status gracefully without introducing infinite delays, ensuring the stream resumes correctly once the log file has content.
• I'll keep the changes strictly on the frontend side, as the server/actuator behavior is out of scope for this fix.

I'll start working on a PR following these guidelines. Thanks for the guidance!

[cdprete]

• Regarding the polling: I’ll make sure the logic handles the 416 status gracefully without introducing infinite delays, ensuring the stream resumes correctly once the log file has content.

Can you please describe how you plan to achieve this?

[MohammedGhallab]

• Regarding the polling: I’ll make sure the logic handles the 416 status gracefully without introducing infinite delays, ensuring the stream resumes correctly once the log file has content.

Can you please describe how you plan to achieve this?

To handle the 416 status efficiently, I plan to implement a reactive retry strategy using Project Reactor's retryWhen.

Specifically, when a 416 error occurs (indicating the log file is currently empty or the range is invalid), the stream will not terminate. Instead, it will trigger an exponential backoff (e.g., starting at 1s and capping at 30s). This prevents 'infinite delays' by ensuring the polling frequency decreases if the file remains empty, while automatically resuming normal streaming as soon as new content is appended to the log file.

I will also ensure that the WebClient state is preserved so that the next request starts from the last known valid byte offset once the 416 condition is cleared.

[cdprete]

Specifically, when a 416 error occurs (indicating the log file is currently empty or the range is invalid), the stream will not terminate. Instead, it will trigger an exponential backoff (e.g., starting at 1s and capping at 30s).

Which basically would cause to have to wait up to 30s in case we reach the capped value and there are some logs available.
That's not ideal at all.

I will also ensure that the WebClient state is preserved so that the next request starts from the last known valid byte offset once the 416 condition is cleared.

I think, @SteKoe correct me please if I'm wrong, that the backend so far it's stateless and it doesn't keep track of such things, because there is no special service just for the log file, but a global proxy to forward accordingly all the requests targeting the actuator endpoint for an instance.
While keeping such a state around for now would not be a big deal, it would seriously compromise the scalability of SBA if one day the team would decide to split, in terms of deployables, the frontend from the backend.

[cdprete]

For what I can read online, it seems like this can't really be addressed since it's caused by the browser itself for security reasons.
Therefore, unless the team knows more, this can be closed for me.