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 you prefer filling the table approach , let me know. However, that would make the code a bit more complex.

I would because currently it looks quite awkward, especially considering that going one page back simply renders then everything.

Also, will going back always render everything or will also work in chunks?
As said previously, I'm worried when there are big log files to render.

[vetri15]

Hi @cdprete

No , going back would only render the previous 300KB of text. Suppose if there were
400KB of skipped bytes , then on first 'back' it would render 100-400 window , and on next back it would render 0-100. So technically while going back to the start of the file would also result in few lines rendered on the table. Should I also change this behaviour to fill the table?

[cdprete]

Yeah, if possible, I would try to fill the table up. The ideal implementation would be to show, on every page up/down, exactly enough lines to fill the table but that don't render the vertical scrollbar. But that would be too complex to implement. :) Il mer 27 mag 2026, 06:54 vetri15 ***@***.***> ha scritto:

…

*vetri15* left a comment (codecentric/spring-boot-admin#5390) <#5390 (comment)> Hi @cdprete <https://github.com/cdprete> No , going back would only render the previous 300KB of text. Suppose if there were 400KB of skipped bytes , then on first 'back' it would render 100-400 window , and on next back it would render 0-100. So technically while going back to the start of the file would also result in few lines rendered on the table. Should I also change this behaviour to fill the table? — Reply to this email directly, view it on GitHub <#5390?email_source=notifications&email_token=ACAZGWHPF7RXO7IUQ5FOLXL44ZYIXA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINJVGE2DCOJSGMZKM4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-4551419232>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACAZGWA4PDJLZ7D2KMW2ADT44ZYIXAVCNFSM6AAAAACZLAJ6V2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DKNJRGQYTSMRTGI> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[vetri15]

Hi @cdprete ,

I have updated the PR and implemented fixes for the remaining bugs.

For navigation near the start or end of the file, I am overlapping bytes to keep the table filled using the existing 300 KB chunk size.

regarding the table not being filled near start and end: Rendering exactly the number of bytes needed to fill the table is difficult because wrapped lines take uneven vertical space. Zooming in or out also changes how many lines are needed to fill the visible table area. So keeping a fixed 300 KB chunk with boundary overlap is a more stable approach.

bugs/issues	comments	status
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	❓
5. on server reboot it appears and the UI doesn't really recover from it unless it's manually reloaded	Implemented a retry mechanism , that keeps retrying until network is back again , if it is back withing 10 retries , it would continue with normal followmode , if it comes online after more than 10 retries it will do a complete reset , kind of like a page refresh and starts following logfile.	✅
6. manual navigation renders some remaining lines with broken style	It was a small bug , i missed adding the w-full for the table, added the css class	✅
7. 416 error message spam on console	the previous assumption of this error diagnosed as related to manualmetadata polling was wrong , it was requesting new chunks when already at the EOF , it is patched now	✅