SEZ9 commented on PR #12299: URL: https://github.com/apache/seatunnel/pull/12299#issuecomment-5691579987
Thanks for the follow-up — `a9612322a` and the spotless fix in `5192320` look like real movement after `b9190ef5`, which was identical to `12b99ec9`. I have not yet been able to walk the new diff myself, so rather than mark anything resolved, could you confirm the status of each earlier point below? - **F1 – charset:** does the bounded/tail path of `readFileTailToStr` decode with the same charset as the unlimited path, so the same file is never decoded differently depending on its size? - **F3 / F4 – truncation marker:** is the notice prepended by `LogContentReader` applied on both the multi-node and single-node log endpoints whenever the response is not the full file? - **F2 / F6 – compatibility & v1 docs:** is the default 64 MB tail truncation recorded in `incompatible-changes.md`, and are `rest-api-v1.md` (en and zh) updated to describe the bounded behaviour and the `log-response-max-size-mb` option, not just the v2 page? - **F7 – docs wording:** do the docs still hard-code "last 64 MB" instead of referring to the configured value, and is the stray double backtick in the zh page fixed? - **F5 – extra copies in `tailFromLineStart`:** does the new implementation still copy the retained window a second time? A short note on how many times the tail is materialised per request would help judge whether that is acceptable for now. - **F8 – duplicated MB-to-bytes / `<= 0` handling:** with `LogContentReader` now shared, is that conversion and sentinel logic consolidated there rather than repeated in `LogBaseServlet` and `LogService`? Once those are confirmed I'm happy to do a final pass. <!-- streview-comment:1084 --> -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
