feat(#4342) logfile view - chunk navigation

[vetri15]

Implemented logfile chunk navigation and recovery improvements.

• Added previous/next chunk navigation
• Show skipped and remaining byte counts
• Render only complete log lines across chunk boundaries
• Automatically reset and resume follow mode after logfile compression
• Improved tail-follow scroll behavior and manual chunk navigation

[vetri15]

Hi @cdprete,

I created a new PR for issue #4342, as I realized my previous approach would not be sufficient to implement this feature cleanly.

I think the previous PR(#5326) can be closed. Could you please review the new PR and let me know if any further changes are needed?

It took longer than I initially expected because of the edge cases involved.

[cdprete]

Hi @vetri15.

You can close the old PR yourself if you think the new one supersedes it.

Could you please review the new PR and let me know if any further changes are needed?

I try to do it asap.

It took longer than I initially expected because of the edge cases involved.

No worries.

[cdprete]

@SteKoe @erikpetzold @ulischulte @hzpz can you maybe allow the pipeline to run in the meantime so that we make sure there are no potential issues? Tnx

[vetri15]

Yeah, you were right @cdprete.

I have closed the old PR.

[cdprete]

By the way, please be aware that there are issues with empty lines.
I don't know if your PR already covers it somehow, but for details have a look at #5388.

[vetri15]

Hi @cdprete,

Thanks for pointing this out. I checked #5388 and updated this PR to handle empty log lines in the logfile view as well.

Empty strings are now rendered as <br> instead of an empty <pre>, so blank lines from the log file are preserved visually. I also brought over the related logfile styling from #5388 for tr, td, br, pre, and logfile links.

[cdprete]

Hi @cdprete,

Thanks for pointing this out. I checked #5388 and updated this PR to handle empty log lines in the logfile view as well.

Empty strings are now rendered as <br> instead of an empty \<pre\>, so blank lines from the log file are preserved visually. I also brought over the related logfile styling from #5388 for tr, td, br, pre, and logfile links.

Hi @vetri15.

I just wanted to inform you I updated the styles in my PR as follows:

• removed w-full from pre and br since on tr and td is already enough
• changed the on-hover target from pre to td to respect also the empty new lines, but it seems like it's already working on your branch as it should

[cdprete]

I tested this a bit and discovered the following bugs/issues:

• the first line in the log file is lost:

vs even if it's actually returned by the call

• with the tailing disabled, entering the manual navigation mode requires to press the down arrow twice but, for some reason, if then the up arrow is pressed ('cause I want to check the previous chunk for example), it's again required to press the down arrow twice to properly navigate the content
• the manual navigation puts the scrollbar at the bottom by default, while ideally should be at the top 'cause you want to read the current chunk top to bottom and not have to scroll with scrollbar to the top then to read it. Especially because it jumps over quite some lines
• no errors are shown anymore, while they're there in the console. While this may be wanted for some specific errors (e.g.: 416), even errors like "Connection Refused" are not shown anymore, therefore someone presses the arrows but nothing really happens. To simulate this, just stop the backend server.
• On server reboot it appears and the UI doesn't really recover from it unless it's manually reloaded, even if the server is up in the meantime:

• As soon as the manual navigation renders some remaining lines on, let's say, a new page (so not a continuation of the current one) the styles are broken. No scrollbars, no w-full and so on:

• I think there may be some issues on how the ranges are calculated. Even by using the previous follow/tail mode, there are now way more 416 in the console:

• The tooltip on the follow/tail button always says "Resume following" which is wrong if such a mode is already active

[vetri15]

Hi @cdprete , I have summarized the issues you mentioned before. have corrected most of them. need your input on the remaining ones.

bugs/issues	comments	status
1. the first line in the log file is not shown	none	✅
2. manual navigation mode taking two clicks to navigate	none	✅
3. the manual navigation puts the scrollbar at the bottom by default	I was not able to replicate it , however my suspicion was when switching from follow mode to manual mode , the $nextTick(() => this.scrollToBottom();) from follow mode is spilling over to manual mode for one tick, so I added a guard check. I hope this is solved , if not please let me know	❓
4. all errors were suppressed	none	✅
5. on server reboot it appears and the UI doesn't really recover from it unless it's manually reloaded	Need some help replicating this scenario , I am testing this on a random springboot where if i stop and start an application it will start with a new instance Id. after doing some research, even in cloud environments only some carry the meta data like instance Ids when restarting. need your input on how to tackle this.	❓
6. manual navigation renders some remaining lines with broken style	I am not able to understand clearly , in manual mode we are traversing either previous or next chunk so either way it would be a continuation. correct me if my understanding is wrong	❓
7. 416 error message spam on console	I am not able to replicate it , however while it might be cause. I did not handle the logfile compression in the ManualMetadataPolling , I have corrected it so the 416 error spam should be gone.	❓
8. tool tip not showing proper label when in follow mode	Have added a i18n label - "stop following" which would be seen when in follow mode.	✅

[cdprete]

Hi @vetri15.

I was not able to replicate it , however my suspicion was when switching from follow mode to manual mode , the $nextTick(() => this.scrollToBottom();) from follow mode is spilling over to manual mode for one tick, so I added a guard check. I hope this is solved , if not please let me know

I'll give it a new try as soon as I've some more time and I let you know.

Need some help replicating this scenario , I am testing this on a random springboot where if i stop and start an application it will start with a new instance Id. after doing some research, even in cloud environments only some carry the meta data like instance Ids when restarting. need your input on how to tackle this.

I'm using the servlet sample which is already part of the project. Maybe it helps.

I am not able to understand clearly , in manual mode we are traversing either previous or next chunk so either way it would be a continuation. correct me if my understanding is wrong

Yes and no. I mean, if "remaining" is not 0, you're now fetching it and rendering it.
As soon as this is the case, as it can be seen in the screenshot above, instead of rendering it as a continuation the new lines get somehow rendered as a new page and the styles are broken.

I am not able to replicate it , however while it might be cause. I did not handle the logfile compression in the ManualMetadataPolling , I have corrected it so the 416 error spam should be gone.

I'll give it a new try as soon as I've some more time and I let you know.

[cdprete]

Hi @vetri15.

This (it's the latest version you committed, btw) maybe shows better what I meant with the styles getting broken:

As you can see in the red section, w-full is somehow not applied anymore, but only as soon as the manual navigation is used to see a remaining chunk.
The same is true for the missing scrollbars which are, instead, present in follow mode.

Also, I can still see 416 responses flooding the console:

,the log file has NOT been compressed yet and, for what I can see, it's one error every 1s roughly.
See the counter of the failed requests going up in the video below:

Video.Project.mp4

The navigation seems to be worse now than in the previous version, in particular in the following flow:

• stop the follow mode and let it accumulate some logs
• press the arrow down to render the chunk which can lead to 3 scenarios:

1. the down arrow is still active and, pressing it again, produces the rendering of just other X lines without concatenating them to the previous ones, even if there is plenty of space in the page
2. the down arrow is disabled --> let it accumulte some more logs and repeat --> on click it will just render the new lines without appending them to the existing ones (the same as in 1)
3. the down arrow is disabled --> let it accumulte some more logs and repeat --> on click it will happen the new line (maybe because it's only one?) to the existing ones, therefore working as expected (but I'm not certain of this, I need to carefully check the log lines)

See below:

Recording.2026-05-26.200614.mp4

Also, unless I've maybe too few logs, the navigation between chunks is not really possible. On page up, the full logs gets then rendered again, instead of just the previous chunk which makes me wonder what happens if the log file has GB of text in it.

[vetri15]

Hi @cdprete

my bad, I missed that style missing. I have corrected that in my local repo. will push it once all issues are solved. I am working on the UI auto recovering on stop and start of a server. have decided to do a retry logic for a few seconds before resetting the page. so there will be no need of manual refresh.

---

416 spam error:

Also, I can still see 416 responses flooding the console:

Thanks for the insight , I was able to pinpoint the cause of error. when appending new bytes if the request is on the edge of the byte range , it is causing the error. previously I was testing with a slightly higher frequency quartz job , so it went unnoticed.
Once I clear these bugs, I’ll let you know.

---

Regarding that, Manual file navigation rendering few lines , it was intentional based on the following discussion on the previous PR (#5326), #5326 (comment),

If you prefer filling the table approach , let me know. However, that would make the code a bit more complex.

[cdprete]

Hi @vetri15,

If we decide to go up (previous), first click will scroll up , second click will load chunk, it will be scrolled down on the newly loaded chunk, so we need to press twice again to load the previous chunk.

I would say: first click scrolls up, second click loads the chunk and scrolls up, so that the view makes visible the chunk from the beginning

If we decide to go down(next) , first click will scroll down , and the second click will load chunk , it will be scrolled down on the newly loaded chunk , so don't need the two click routine for traversing a single chunk.

I would say: first click scrolls down, second click loads the chunk and scrolls up, so that the view makes visible the chunk from the beginning

In a nutshell:

• 1st click: scroll in the direction of the arrow
• 2nd click: load the chunk and scroll up to make it readable from the beginning

I'm not sure about the scroll up for visibility purposes, though. I would need to see the outcome of it.

I was talking about this asymmetry ,for consequent traversal : one click for down but two click for traversing up.

This would be true only if you're already at the bottom and it's not really asymmetrical. It's just that when you're at the top you can't go further up.
Imagine that you could, it would require only one click as well.

[vetri15]

Hi @cdprete ,

In a nutshell:
1st click: scroll in the direction of the arrow
2nd click: load the chunk and scroll up to make it readable from the beginning

Implemented the requested change , can you please check and tell whether it is working as expected

[cdprete]

Hi @vetri15,

can you please check and tell whether it is working as expected

I'll give it a try tomorrow at max.

I've a question about the remaining bytes counter, though: is it there purely for display purposes or do you use it also for something?

I was thinking that, during the manual navigation, it may be an overkill.
Imagine I'm reading the chunk 1 and, in the meantime, other 10 chunks get written. It's quite wasteful to load them just to show a counter and, therefore, I would rather drop it.

On the other end, to make the manual navigation smoother, I would embrace the idea of prefetching and storing and previous and next chunk of the currently rendered one, so that on page up/down there are no delays. Of course, capped by a new line, so there may be the need to prefetch more than just one, or none at all if not available (e.g: we are on the 1st chunk -> no prev, we are on the last church and the pull of the next fails -> no next).
Probably the prefetching of the next chunk is trickier and requires careful implementation, though.

What do you think?

[vetri15]

Hi @cdprete ,

I've a question about the remaining bytes counter, though: is it there purely for display purposes or do you use it also for something?

The remaining bytes counter is mostly display, but the underlying total size is also used to know whether the user can navigate to the next chunk. In manual mode we’re not fetching logfile contents for that. It just uses the existing poll timer to check the current logfile size/metadata. So it doesn’t load the chunks in between just to show the remaining bytes.

On the other end, to make the manual navigation smoother, I would embrace the idea of prefetching and storing and previous and next chunk of the currently rendered one, so that on page up/down there are no delays

I definitely like the adjacent prefetching idea, But I’d prefer to handle that as a separate issue/feature request, since it needs a bit more careful handling around partial lines, resets/compression, logfile growth, and failed prefetches. This PR is already getting a little complex/bigger than expected.

Let me know what you think.

[cdprete]

Hi @vetri15,

In manual mode we’re not fetching logfile contents for that. It just uses the existing poll timer to check the current logfile size/metadata.

I don't follow. To check such values you have no other way apart calling /logfile with a range. But this will return that portion of the logs as well, even if it's then discarded.
I wonder if we could, at least, stop polling as soon as we know there is at least another chunk available.
Otherwise, depending on the log file content, we may download MB of data over the wire for nothing.
This is especially true when we hit a size which is bigger than the chunk size.

But I’d prefer to handle that as a separate issue/feature request, since it needs a bit more careful handling around partial lines, resets/compression, logfile growth, and failed prefetches.

Indeed. I was not asking to implement it as of now.

[vetri15]

Hi @cdprete,

To check such values you have no other way apart calling /logfile with a range. But this will return that portion of the logs as well, even if it's then discarded

Not really , there is a shortcut :D , fetching range 0-0

HTTP/1.1 206 Partial Content
Content-Range: bytes 0-0/4707
Content-Length: 1

so the app just polls this endpoint , so does not download data , it just pings with the same frequency of polltimer config property used in follow mode , except this one does not fetch any content.

[cdprete]

Hi @cdprete,

To check such values you have no other way apart calling /logfile with a range. But this will return that portion of the logs as well, even if it's then discarded

Not really , there is a shortcut :D , fetching range 0-0

HTTP/1.1 206 Partial Content
Content-Range: bytes 0-0/4707
Content-Length: 1

so the app just polls this endpoint , so does not download data , it just pings with the same frequency of polltimer config property used in follow mode , except this one does not fetch any content.

Hi @vetri15.

That's interesting.
I would have expected such a range configuration to fail.
How did you figure it out?
There is no mention of such an edge case in https://docs.spring.io/spring-boot/api/rest/actuator/logfile.html.

[vetri15]

Hi @cdprete ,
Honestly, I didn’t find it. I asked ChatGPT how to find the size of the logfile. it gave me this trick and I checked , it worked :D .

That's interesting.
I would have expected such a range configuration to fail.

Yea , i was also skeptical too. but suppose if it failed i would have pestered the endpoint with 0-1 range , surely it can't reject that ;)

[cdprete]

Hi @vetri15.

I tested it again and I realized that my idea to scroll to the top on the first page down is actually a bad idea, because, at least when using just the arrows, we're already at the bottom.
Or, to be precise, the idea would be good if we would be rendering the new chunk directly but, it seems like, that we render some old lines instead.
For example, the last line has time 12:12:41:ms but then, when the scrollbar gets moved to the top, I ended up with a line having 12:12:31:ms as time.
I was actually, instead, especting to get the next chunk rendered from the top and, therefore, the first line should have a time > 12:12:41:ms (with potentially only greater ms depending on the volume of the logs).

Video.Project.2.mp4

For the page up, this problem doesn't occur, though. But that's to be expected because, on page up, we are basically navigating through some history and therefore the data must be in the past.

I don't know how we could fix this. Any suggestions?

For the rest, it looks fine to me.

[vetri15]

Hi @cdprete ,

For example, the last line has time 12:12:41:ms but then, when the scrollbar gets moved to the top, I ended up with a line having 12:12:31:ms as time.

Maybe this idea might work:

logic: scrolling dynamically based on direction, page down -> scroll bottom and for page up -> scroll to top.

page down:
case 1: trying to page down when near the file end. we press page down. it would load few bytes and there will be overlap since we are near file end. but since we scroll to bottom. the user won't get confused. suppose if they want to read from the top of page. they can just press up once and go to top.

case 2: trying to page down near the middle chunks. we press down. it would load next page and scroll to bottom. and next press would also do the same.

page up: remains unaffected.

this also inadvertently solves the asymmetry while traversing page i was talking about. since while going in one direction would automatically scroll in that direction , we would only need one click for one chunk on a big file.

what do you think about this approach ?

[cdprete]

Hi @vetri15.

case 1: trying to page down when near the file end. we press page down. it would load few bytes and there will be overlap since we are near file end. but since we scroll to bottom. the user won't get confused. suppose if they want to read from the top of page. they can just press up once and go to top.

As soon as the overlap doesn't produce duplicated log entries in the view, it sounds ok.

case 2: trying to page down near the middle chunks. we press down. it would load next page and scroll to bottom. and next press would also do the same.

Won't this skip a chunk, though, because on the second click we scroll to the button and therefore jump at the end of the chunk, therefore reintroducing the previous issue that you've to scoll manually all the way up? Or am I missing something?

I kind of had the impression, but I've to try again, that the issue was occurring only when the remaining bytes were less (or equal, maybe) than the chunk size. If there were more remaining bytes than the chunk size then the scolling up was indeed positioning the log view at the first line of the new chunk.

what do you think about this approach ?

It it works I'm good with it.
Maybe you can give it a try, let me test it and I report back to you if the issue is solved or not.

[vetri15]

Hi @ccdprete,

Won't this skip a chunk, though, because on the second click we scroll to the button and therefore jump at the end of the chunk, therefore reintroducing the previous issue that you've to scroll manually all the way up? Or am I missing something?

yea , you are right. in a way, my suggestion would replace the visual overlap issue with the skipping few lines visually. which is not ideal.

I think a proper solution would be track the line the user is viewing and pass it to the next chunk. so it scrolls to the next/previous line based off that when near start or EOF.

I will try implementing such a solution and then let you know for test.

[cdprete]

Hi @ccdprete,

Won't this skip a chunk, though, because on the second click we scroll to the button and therefore jump at the end of the chunk, therefore reintroducing the previous issue that you've to scroll manually all the way up? Or am I missing something?

yea , you are right. in a way, my suggestion would replace the visual overlap issue with the skipping few lines visually. which is not ideal.

I think a proper solution would be track the line the user is viewing and pass it to the next chunk. so it scrolls to the next/previous line based off that when near start or EOF.

I will try implementing such a solution and then let you know for test.

Hi @vetri15.

How do you plan to detect on which line the user is correctly? Won't you have the issues already discussed about wrapping, zooming and density?

[cdprete]

Hi @vetri15.

I kind of had the impression, but I've to try again, that the issue was occurring only when the remaining bytes were less (or equal, maybe) than the chunk size. If there were more remaining bytes than the chunk size then the scolling up was indeed positioning the log view at the first line of the new chunk.

I had a 2nd try on this and, if I'm not mistaken (it's hard to say it certainly given the volume of the logs), indeed I can see the next chunk being rendered more or less correctly (sometimes there is a single previous line from the previous one, but it's acceptable) when the remaining bytes >= 300kB (which is the chunk size).

Can you please give this a try also from your side? Maybe I get this behaviour by pure luck. :D

So, I would suggest the following approach:

• if remaining bytes < chunk size: scroll to the bottom and (kind of) append the new (small) chunk to it
• it remaining bytes >= chunk size: keep the current logic of scrolling to the top and rendering the chunk

What do you think?
I think this should be easier to achive then try to track where the user is in the log view.

[vetri15]

Hi @cdprete,

How do you plan to detect on which line the user is correctly? Won't you have the issues already discussed about wrapping, zooming and density?

The previous strategy was to divide the viewport height by the line height, but that fails when lines wrap. So we would either need to use an average value or accept an approximate line position.

There may be an alternate strategy: if we add a key to the table rows/lines, we can use that key to scroll back to the desired line. This would be harder to implement than the previous static approach, but more reliable.

So, I would suggest the following approach:
if remaining bytes < chunk size: scroll to the bottom and (kind of) append the new (small) chunk to it
if remaining bytes >= chunk size: keep the current logic of scrolling to the top and rendering the chunk

This approach looks fine. There may be a small byte skip when remaining bytes < chunk size, but it is much easier to implement than tracking the exact line.

I’ll first try the line-tracking approach using a line key, since that could also be useful later for virtual scrolling or custom page search. If that turns out to be unreliable or too complex, I’ll fall back to the simpler approach above, accepting the minor imperfections.

Does that sound okay?

[cdprete]

Hi @vetri15,

Does that sound okay?

Sure.

There may be a small byte skip when remaining bytes < chunk size

How? I fail to visualize this. You're just appending at the bottom in that case.

There may be an alternate strategy: if we add a key to the table rows/lines, we can use that key to scroll back to the desired line.

How would you know to which line to scroll?

[vetri15]

Hi @cdprete,

How? I fail to visualize this.
You're just appending at the bottom in that case.

you would be right in most cases, it is a simple append in the bottom. however since we are using a static chunk size 300KB in this case , the small append might not always be small in relation to the viewport.

suppose we are viewing the chunk 100 KB-400 KB , we have remaining bytes = 250KB (total size : 400 + 250 = 650 KB)which is lesser than 300KB(case: remaining bytes < chunk size ), so it won't trigger a complete new chunk. so we could scroll to the bottom. since the 250KB is big compared to the view port. say the viewport can only render 50KB (visual part on the screen not the actual bytes stored in current chunk) , when we click next chunk. It will load the chunk from 350KB-650KB which is correct. but ideally it should scroll to the exact line at 401KB. but with our static approach of scrolling up or down , would result in seeing the wrong lines visually,

• scroll up -> we would be seeing 350KB (overlap)
• scroll down -> we would see 650KB. (skipping)

.so if we add a linekey = lineStart--lineEnd , we can scroll to the first line that is > 400KB , JavaScript supports scrolling to a specific line with the key . so we would be looking at 401KB line , which is exactly what we want for the continuity of reading logfile.

Hope that clarifies.
Once I implement it would be clearer when we compare the new implementation with previous implementation.

[cdprete]

Hi @cdprete,

How? I fail to visualize this.
You're just appending at the bottom in that case.

you would be right in most cases, it is a simple append in the bottom. however since we are using a static chunk size 300KB in this case , the small append might not always be small in relation to the viewport.

suppose we are viewing the chunk 100 KB-400 KB , we have remaining bytes = 250KB (total size : 400 + 250 = 650 KB)which is lesser than 300KB(case: remaining bytes < chunk size ), so it won't trigger a complete new chunk. so we could scroll to the bottom. since the 250KB is big compared to the view port. say the viewport can only render 50KB (visual part on the screen not the actual bytes stored in current chunk) , when we click next chunk. It will load the chunk from 350KB-650KB which is correct. but ideally it should scroll to the exact line at 401KB. but with our static approach of scrolling up or down , would result in seeing the wrong lines visually,

• scroll up -> we would be seeing 350KB (overlap)
• scroll down -> we would see 650KB. (skipping)

.so if we add a linekey = lineStart--lineEnd , we can scroll to the first line that is > 400KB , JavaScript supports scrolling to a specific line with the key . so we would be looking at 401KB line , which is exactly what we want for the continuity of reading logfile.

Hope that clarifies. Once I implement it would be clearer when we compare the new implementation with previous implementation.

HI @vetri15.
I understood what you mean now. Thanks for sharing.

[vetri15]

Hi @cdprete,

I updated the code to store the previously read line by storing a line key in the format byteStart-byteEnd.

• This allows the UI to restore the scroll position to the last read line when loading partial pages.(also added small yellow color highlight during partial load to figure out next line )

The line-key would also be useful, if we decide to add regex search and scroll to the desired line.

Can you try it out and tell if it needs any changes ?

[cdprete]

Hi @vetri15.
I'll try to test it again over the weekend. Tnx.

[cdprete]

Hi @vetri15.
I had a try with the new changes and I see that, from time to time, we carry over some leftover (highlighted in yellow below):

Given that the wrapping is disabled, I don't expect that (part of) line to be there.
Any clue what the cause may be?

Also, the chunks are still somehow not really respected.
For example:

• Current chunk start:

• Go up once to load the previous and then down twice to reload that chunk, but the start is now either broken:

• or it doesn't match since I get a different starting line, but not every time so it's a bit difficult to show/reproduce.

Moreover, the broken lines seems to be a consistent problem.
Even navigating back and forth, they stay broken, like if they were stored broken to begin with and always that broken value gets used:

Video.Project.3.mp4

The issue with the broken lines should indeed be fixed since it was not the case in the previous version and I can easily see other people complaining for it.
Also, the tail mode should not be automatically activated if the log files rotates because it's pretty much confusing.
Ideally we should just reset the state of what it's currently rendered, render the new and fresh new chunk from the new log file and allow people to just continue the manual navigation (which will probably initially be disabled, depending on how many new bytes are now remaining).
I can leave with the log lines/chunk not perfectly positioned while navigating.

[vetri15]

Hi @cdprete ,

I had a try with the new changes and I see that, from time to time, we carry over some leftover (highlighted in yellow below)

Yes , I could also see the some inconsistent line change from moving to next chunks. I will look into this.

Also, the tail mode should not be automatically activated if the log files rotates because it's pretty much confusing.
Ideally we should just reset the state of what it's currently rendered, render the new and fresh new chunk from the new log file and allow people to just continue the manual navigation (which will probably initially be disabled, depending on how many new bytes are now remaining).

I previously implemented locally such that the file rotation would carry forward the previous mode , either Follow or Manual mode. but carrying forward the Manual mode was difficult due to following cases:

• If the user is in manual mode , then if the logfile resets with the manual mode, on the first polling it would fetch only a few lines. so we would end up with only few new lines in the user view which though correct looked broken. or we could set that if manual mode while also fetching some lines until the lines fill the user view. however the latter is almost same as follow mode.
• If we reset the state internally , but while allowing user to use manual navigation to navigate to the newly (rotated logfile) rendered chunk will work only when the user is previously at the end of the file (logfile before rotation).
  if the user is not on the latest chunk in manual navigation , allowing the user to navigate seamlessly to the newly rotated chunk will give the wrong impression that user is has not skipped any bytes in between. so giving a file rotated warning would in some case give a head's up that there might be some lines.

due to these issue I thought it is better to reset and set in follow mode on file reset.

alternate solution: since automatically doing this without user interaction might make this confusing , we can have a reset on next interaction flag. with this implementation , if it detects file rotation. it won't force refresh the page. unless user interacts such as next page or previous page.

please let me know your thoughts on this approach.

[cdprete]

Hi @vetri15,

If we reset the state internally , but while allowing user to use manual navigation to navigate to the newly (rotated logfile) rendered chunk will work only when the user is previously at the end of the file (logfile before rotation).
if the user is not on the latest chunk in manual navigation , allowing the user to navigate seamlessly to the newly rotated chunk will give the wrong impression that user is has not skipped any bytes in between. so giving a file rotated warning would in some case give a head's up that there might be some lines.

I don't follow. This is already the case as of today.
If the file gets rotated, you can't anyway fetch anymore any chunk from it, indipendently of the fact you're already at the end or not.

Nevertheless, let's fix the broken lines for now and keep the rest as it is, otherwise I think we'll never finish this.