Bug: Logfile Content Incorrectly Parsed as Object in Log Tail View

[AkshayKumarCB]

Spring Boot Admin Server information

• Version: 3.5.0
• Spring Boot version: 3.5.1
• Configured Security: basic-auth
• Webflux or Servlet application: webflux

Description

When viewing the log tail in the Spring Boot Admin UI, the following error is thrown in the browser console despite the logfile being fetched successfully from the actuator endpoint:

Fetching logfile failed: TypeError: i.data.indexOf is not a function
    at logtail.ts:64:60

The error occurs because i.data — which is expected to be a plain string — is instead an object. This causes .indexOf() to fail, as that method is not available on objects.

Affected File

spring-boot-admin-server-ui/src/main/frontend/services/logtail.ts — approximately line 64.

Steps to Reproduce

1. Configure a Spring Boot application with structured/JSON logging (e.g. Logstash, logback-json encoder)
2. Enable the logfile actuator endpoint
3. Make sure that the logfile contains exactly a single logline in JSON format without a newline at the end.
4. Open Spring Boot Admin and navigate to the Logfile tab for the application
5. Observe the error in the browser console: TypeError: i.data.indexOf is not a function

Expected Behavior

The logfile content should be returned and handled as a plain string, and the log tail view should render successfully.

Actual Behavior

Axios converts the response body into a JavaScript object, causing .indexOf() to throw a TypeError, and the log tail view fails to render.

[AkshayKumarCB]

The root cause seems to be in logtail.ts, where the Axios HTTP GET request is done (via getFn()).

Axios has a built-in default transformResponse pipeline that attempts JSON.parse() on all string responses by default, regardless of the Content-Type returned by the server. Even when the /actuator/logfile endpoint correctly responds with Content-Type: text/plain, if any portion of the log content resembles valid JSON (e.g. structured log output such as {"level":"INFO","msg":"started"}), Axios will silently convert the entire response body into a JavaScript object instead of keeping it as a raw string.

I suspect that the solution is to just add responseType: text to the request to make it work.

[cdprete]

Unfortunately the Content-Type header seems to be completely ignored (maybe you want to file a bug for the axios team about this) in https://github.com/axios/axios/blob/main/lib/defaults/index.js#L100 but, given the logic in there, setting the responseType: text as suggested should be enough I think.

[cdprete]

With the version on master I can't reproduce the issue.

I tested it by adding a application-json.yml in the servlet/reactive sample application with the content:

logging:
  structured:
    format:
      file: logstash

and by running the application with the profiles dev,insecure,json.
Either with the responseType: text set or without, I observe no errors in the console and the logs are rendered correctly in the logfile view:

[AkshayKumarCB]

@cdprete, thank you for the investigation. It does work fine under normal circumstances.

However, if you look at the 'Steps to reproduce' section, you would notice that the problem occurs only when the logfile has exactly one log in JSON format. It does not happen when there's more than one logline because 'axios' parses it like a normal text file. It converts the response to JSON only when it can actually parse the response into a JSON object.

It is an edge case scenario. It does not happen under normal circumstances. So, all you'd need to do is reduce the number of logs in the logfile to just one and then see if you hit the reported problem.

[cdprete]

@AkshayKumarCB have you by chance verified if this also happens with the latest released version?
The SBA version you reported is almost 1 year old and, most probably, Axios was updated (many times :D) in the meantime.

Adding that flag wouldn't hurt anyway IMO given that it would be applied only in the config object passed to logtail which, in return, is used only by the logview, but I can't say from my side.

[AkshayKumarCB]

@cdprete, what you suggest makes sense (didn't realize the SBA version was one year old!). Since the code hadn't changed much for a long time, I made a bad assumption that it should be in the latest releases as well. I'll test with the latest version and close if I can't reproduce. Thank you for your patience!

[cdprete]

@cdprete, what you suggest makes sense (didn't realize the SBA version was one year old!). Since the code hadn't changed much for a long time, I made a bad assumption that it should be in the latest releases as well. I'll test with the latest version and close if I can't reproduce. Thank you for your patience!

If updating doesn't help, let us know and I can try to replicate the issue better and open a PR with that flag set.
I think there should be no issues, right @SteKoe?

Nevertheless, I'm surprised about the use case. I could never imagine to have a log file with a single entry in it :D
Already Spring Boot itself, when it starts, logs more than a single line.

[cdprete]

Fancy enough, indeed it happens when there is only one log line in the file:

The error seems to be caused by the line:

addendum = response.data.substring(response.data.indexOf('\n') + 1);

in the logtail function which is reached, though, only if indeed the payload gets parsed as JSON because contentLength = response.data.length gets evaluated as undefined and, therefore, contentLength >= size is false.
Setting responseType: 'text' indeed returns a string in response.data and it's then all good.

@SteKoe, maybe to be addressed with another ticket but, if the log file is empty, the polling then starts failing with:

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

and floods the console log.
Ideally such error should be silently ignored (or logged at debug/trace level, if wanted).
Let me know if you want me to open a ticket for it or not.

PR opened: #5289

[AkshayKumarCB]

@cdprete Well, here's the scenario where this happened: We have a bunch of long-running services for which logs are viewed under certain circumstances via the spring-boot-admin logging console UI by our QAs. What happens is that if there's no activity in the service for more than a day (particularly in environments that are less frequently used), our log rotation policy rotates to a new log file every day. We seem to log JVM metrics right after the log rotation happens (which gets logged as a single JSON object line). As a consequence, when our QAs use the logging console UI to view the logfile, we end up hitting the reported error.

This has been around for some time (I remember this error being discussed several times in the past within our team). However, with help from some LLMs, we identified and root-caused this bug rather quickly.

Thank you for taking this over the finish line!