Prevent color bleed and stale prefix on mid-message new entries#1680
Conversation
parse_log_message gave the first line of a multi-line message a
trailing ANSI reset when it carried color but no inline reset, so
the color could not bleed past that one line. A second log entry
that appeared inside the same message got no such protection — it
was emitted as f"{timestamp}{line}" with no reset, even when its
own color code had no closing terminator.
The same branch also left the cached prefix and color from the
first line in place, so any continuation lines that followed the
mid-message entry were rendered with the wrong prefix and the
wrong color.
Apply the same _needs_reset / re-extract treatment to that branch
so mid-message new entries (and any continuations they own)
behave like first-line entries.
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #1680 +/- ##
=========================================
Coverage 100.00% 100.00%
=========================================
Files 25 25
Lines 4143 4156 +13
=========================================
+ Hits 4143 4156 +13 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
Warning Rate limit exceeded
You’ve run out of usage credits. Purchase more in the billing tab. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Pull request overview
Fixes parse_log_message handling of “mid-message new entries” so they (1) get an ANSI reset appended when needed (preventing color bleed) and (2) refresh the cached prefix/color so subsequent continuation lines inherit from the correct entry.
Changes:
- Append
ANSI_RESETfor mid-message new entries when_needs_reset(...)indicates it’s required. - Re-extract
prefix/color_codefor mid-message new entries so later continuation lines use the new entry’s context. - Add focused regression tests covering color-bleed prevention, prefix/color refresh, and
strip_ansi_escapes=True.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
aioesphomeapi/log_parser.py |
Fix mid-message new-entry handling by adding reset-when-needed and updating cached prefix/color for subsequent continuation lines. |
tests/test_log_parser.py |
Adds regression tests covering mid-message new-entry reset behavior and correct prefix/color inheritance (including strip-ANSI mode). |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
The single-line fast path returned the text with timestamp but skipped the trailing-reset check applied on the multi-line first-line path and in LogParser.parse_line. A single chunk like "\x1b[31mhello" (color without inline reset) therefore left the terminal in red, so the next print would inherit the colour — the same bleed bug fixed by esphome#1680 for multi-line first lines.
What does this implement/fix?
parse_log_messagealready appends an ANSI reset to the first line of a multi-line message when it carries color but no inline reset, so the color cannot bleed past that one line. A second log entry that appears later inside the same message did not get the same treatment — it was emitted asf"{timestamp}{line}"with no reset, even when its own color code had no closing terminator. Color could then leak into subsequent output.The same branch also left the cached
prefix/color_codefrom the first line in place. Any continuation lines that followed the mid-message new entry were rendered with the first entry's prefix and the first entry's color, not the new one's.Apply the same
_needs_reset/ re-extract treatment to mid-message new entries so they behave like first-line entries.Types of changes
Related issue or feature (if applicable):
Pull request in esphome (if applicable):
Checklist:
tests/folder).Quality Report
Changes: 2 files changed, 63 insertions(+), 2 deletions(-)
Code scan: clean
Tests: failed (FAILED)
Branch hygiene: clean
Generated by Kōan post-mission quality pipeline