Fix: comment field missing for host notification results in log views - #944
Fix: comment field missing for host notification results in log views#944PhilippLemke wants to merge 1 commit into
Conversation
PainterLogComment.render() used a hardcoded threshold of 6 ";"-separated fields to decide whether a notification log line carries a trailing comment. That threshold only matches the layout of SERVICE notification log lines, which have an extra ";<service>" segment (7 fields with a comment). HOST notification log lines lack that segment, so even with a comment present they only ever reach 6 fields and never cross the "> 6" bar -- the comment column silently stays empty for every host notification, regardless of what the notification plugin wrote to stdout. Extract the threshold into _log_comment_min_fields(log_type), which returns 6 for service log types and 5 for host log types, and have PainterLogComment request the log_type column (already used by the neighboring PainterLogPluginOutput) to pick the right one.
Manual validation on a real 2.4.0p35 environmentI ran this fix on a live 2.4.0p35 (CEE) installation to confirm it behaves correctly outside of the unit tests. Before the fix, Note for anyone backporting this to a 2.4.0 branch
Instead, apply only this targeted hunk to the 2.4.0p35 tree (verified against the real environment above): --- a/cmk/gui/painter/v0/painters.py
+++ b/cmk/gui/painter/v0/painters.py
@@ -4955,6 +4955,19 @@
return ("", row["log_options"])
+def _log_comment_min_fields(log_type: str) -> int:
+ """Minimum number of ";"-separated fields in a notification log line
+ before a trailing comment field is present.
+
+ Host notification log lines have one field fewer than service
+ notification log lines (they lack the ";<service>" segment), so the
+ threshold below which no comment field can be present differs between
+ the two. See cmk.events.log_to_history._format_notification_message,
+ which is the counterpart producing these log lines.
+ """
+ return 6 if "SERVICE" in log_type else 5
+
+
class PainterLogComment(Painter):
@property
def ident(self) -> str:
@@ -4968,13 +4981,13 @@
@property
def columns(self) -> Sequence[ColumnName]:
- return ["log_options"]
+ return ["log_options", "log_type"]
def render(self, row: Row, cell: Cell) -> CellSpec:
msg = row["log_options"]
if ";" in msg:
parts = msg.split(";")
- if len(parts) > 6:
+ if len(parts) > _log_comment_min_fields(row.get("log_type", "")):
return ("", parts[-1])
return ("", "")(Line numbers above are for Disclosure: this PR (code, tests, and this comment) was authored with the assistance of Claude Code (Anthropic). All changes were reviewed and manually validated by me on a live 2.4.0p35 instance before submission. |


Summary
PainterLogComment.render()(cmk/gui/painter/v0/painters.py) decides whether a notification log line carries a trailing comment by checkinglen(parts) > 6on the;-splitlog_optionsstring.;<service>segment (contact;host;service;state;plugin;output;comment= 7 fields with a comment).contact;host;state;plugin;output;comment= only 6 fields, even with a comment present), so they can never cross the> 6bar.log_commentpainter) is silently empty for every host notification, regardless of what the notification plugin wrote to stdout. Service notifications are unaffected.cmk.events.log_to_history._format_notification_message, which explicitly buildsspecdifferently for host (spec = hostname) vs. service (spec = f"{hostname};{service}") — this is the source of the one-field difference.Fix
Extracted the threshold into a small helper,
_log_comment_min_fields(log_type), returning6for service log types and5for host log types (> 5for host is the layout-correct equivalent of the old> 6for service).PainterLogCommentnow also requests thelog_typecolumn (already used by the neighboringPainterLogPluginOutput) to tell host and service log lines apart.Test plan
test_log_comment_field_countintests/unit/cmk/gui/plugins/views/test_painters.py, parametrized over host/service × with/without comment, exercising the field-count logic directly.python -m py_compileon both changed files.pytest/mypy(no local Bazel/hatch dev environment available in the sandbox this was authored in) — please let CI confirm.