Fix Markdown reporter max_length handling - #858
Conversation
| job_state = _DummyJobState(diff="line1\nline2\nline3") | ||
| reporter = MarkdownReporter(report, report.config["report"]["markdown"], [job_state], datetime.timedelta()) | ||
|
|
||
| output = list(reporter.submit(max_length=10)) |
There was a problem hiding this comment.
Wouldn't max_length in the function become negative?
There was a problem hiding this comment.
It only goes negative if a very small max_length is passed. This is because submit() first does max_length -= len(trimmed_msg) and the trimmed_msg string is about 58 chars, so max_length=10 becomes -48. Even then it just trims and does not crash. If you want to avoid that impression, I can change the test to use a value >= 60.
thp
left a comment
There was a problem hiding this comment.
In which situation would max_length actually become None?
|
Agreed that a plain CLI run won't hit this. The crash only happens when the Markdown reporter output is actually consumed (Python/hook/extension usage): with default |
thp
left a comment
There was a problem hiding this comment.
The more I think about it, the more I think that max_length -= len(trimmed_msg) should be done later (only when trimmed is truthy). If it isn't trimmed, we still want to have the full max_length, and if it is trimmed, something like [...] or [trimmed] might be better to allow for more "payload" and less "boilerplate". In particular, if max_length < len(trimmed_msg), then technically we wouldn't be able to show anything, not even the summary or the details. And if the "trimmed message" is quite small (e.g. "[...]" - 5 characters).
Then again, it's probably the _render() method that should do all deciding and value adding (possibly with an additional return value before the footer), so that it knows what the "real" max length is, and either fit the message in there, or trim it.
In other words:
The message "Hello world" (11 characters) and trimmed_msg = "[...]" (5 characters)
with max_length == 11 should still be:
"Hello world"
but with max_length == 10, should be:
"Hello[...]"
Right now, with max_length == 11, it would be:
"Hello [...]"
4f5f740 to
ce8e240
Compare
| trimmed_marker = "[...]\n" | ||
| if len(trimmed_marker) > max_length: | ||
| trimmed_marker = "" | ||
| reserved_length = max_length - len(trimmed_marker) if trimmed_marker else max_length |
There was a problem hiding this comment.
If trimmed_marker is the empty string (the only way if trimmed_marker should evaluate to falsy), then len(trimmed_marker) == 0, so the result is the same.
| reserved_length = max_length - len(trimmed_marker) if trimmed_marker else max_length | |
| reserved_length = max_length - len(trimmed_marker) |
| if len(trimmed_marker) > max_length: | ||
| trimmed_marker = "" | ||
| reserved_length = max_length - len(trimmed_marker) if trimmed_marker else max_length | ||
| trimmed, summary, details, footer = MarkdownReporter._render( |
There was a problem hiding this comment.
It's unfortunate that we have to call MarkdownReporter._render() twice here. Can't MarkdownReporter._render() contain all that trimming logic?
thp
left a comment
There was a problem hiding this comment.
See comments. Ideally call MarkdownReporter._render() only once and let it figure out trimming (since MarkdownReporter._render() already returns the trimmed status, might as well return trimmed_msg instead (being the empty string if not trimmed or not enough space).
|
@PeterDaveHello Any updates here? |
|
Sorry, I forgot this PR, will take a look at it. |
ce8e240 to
e2d8dfc
Compare
Let _render() measure the complete layout before deciding whether to trim, reserving marker space only when necessary. For finite limits, bound summary joining and measure detail bodies before formatting so oversized reports do not materialize the full message. This keeps exact-length output intact, preserves payload with a compact trim marker, separates it cleanly from Markdown footers, avoids None arithmetic and negative slicing, and bounds temporary output for Matrix and Gotify. Tests cover unlimited and bounded output, exact limits, trimming, oversized details, summaries, and footers.
e2d8dfc to
59a1f03
Compare
Fix Markdown reporter handling of unlimited and size-limited output.
max_length=Noneno longer raises aTypeError. Trimming is now handled in_render(), so exact-fit reports remain unchanged while oversized reports preserve as much content as possible with a compact[...]marker. For size-limited reporters such as Matrix and Gotify, oversized details are measured before formatting, avoiding unnecessary memory use for very large diffs.Tests cover unlimited output, exact and tiny limits, trimmed details, footers, and oversized diffs.