fix: Truncate large table samples in Teams alerts to prevent payload size issues#2104
fix: Truncate large table samples in Teams alerts to prevent payload size issues#2104RamiNoodle733 wants to merge 1 commit intoelementary-data:masterfrom
Conversation
…size issues (#2044) When sending alerts to Microsoft Teams with large test result samples (>25 rows with multiple columns), the payload exceeds Teams' limits and gets rejected. This fix adds: - New maximum_rows_in_alert_samples_table config parameter (default: 25) - Table truncation logic that limits rows and adds a message about omitted rows - CLI option --maximum-rows-in-alert-samples-table (-mr) to customize the limit Fixes #2044
|
👋 @RamiNoodle733 |
📝 WalkthroughWalkthroughThis change introduces a new configuration parameter Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Poem
🚥 Pre-merge checks | ✅ 3 | ❌ 2❌ Failed checks (2 warnings)
✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ 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.
Actionable comments posted: 1
🤖 Fix all issues with AI agents
In `@elementary/monitor/alerts/alert_messages/builder.py`:
- Around line 398-417: Guard against non-positive
maximum_rows_in_alert_samples_table by normalizing it before truncation: compute
a safe_max = max(1, self.config.maximum_rows_in_alert_samples_table) (or treat
<=0 as "no truncation" by using safe_max = None and skipping truncation), then
use safe_max when slicing result_sample and when computing omitted_rows_count =
max(0, len(result_sample) - safe_max); update the truncation branch that uses
result_sample[:self.config.maximum_rows_in_alert_samples_table],
omitted_rows_count, TableBlock.from_dicts, LinesBlock and ItalicTextLineBlock to
reference safe_max so you never produce an empty table or negative
omitted_rows_count for 0/negative config values.
🧹 Nitpick comments (1)
elementary/monitor/alerts/alert_messages/builder.py (1)
398-413: No observability when truncation occurs.The PR objectives call for logging a warning when truncation happens. Currently, no log message is emitted. Consider adding a
logger.infoorlogger.warningcall when rows are truncated, so operators can identify which alerts were modified. This would require importing a logger into this module if one isn't already available.
| # Truncate table if too many rows to prevent Teams payload size issues | ||
| if len(result_sample) > self.config.maximum_rows_in_alert_samples_table: | ||
| truncated_sample = result_sample[:self.config.maximum_rows_in_alert_samples_table] | ||
| omitted_rows_count = len(result_sample) - self.config.maximum_rows_in_alert_samples_table | ||
| result_blocks.append( | ||
| TableBlock.from_dicts(truncated_sample), | ||
| ) | ||
| result_blocks.append( | ||
| LinesBlock( | ||
| lines=[ | ||
| ItalicTextLineBlock( | ||
| text=f"... and {omitted_rows_count} more rows (truncated to prevent payload size issues)" | ||
| ), | ||
| ] | ||
| ) | ||
| ) | ||
| else: | ||
| result_blocks.append( | ||
| TableBlock.from_dicts(result_sample), | ||
| ) |
There was a problem hiding this comment.
Consider guarding against non-positive maximum_rows_in_alert_samples_table values.
The truncation logic works correctly for positive values. However, if a user passes 0 or a negative value via CLI (e.g., --maximum-rows-in-alert-samples-table 0), the behavior degrades:
- 0:
result_sample[:0]→ empty table, with a message saying "and N more rows" for all rows. - Negative:
result_sample[-k:]silently drops rows from the start instead of limiting from the end, andomitted_rows_countbecomes negative, producing a nonsensical message like "... and -5 more rows".
A simple guard (either in the config or here) would prevent this.
Proposed fix (in config or CLI layer)
Option A — Validate at the config level in config.py:
self.maximum_rows_in_alert_samples_table = self._first_not_none(
maximum_rows_in_alert_samples_table,
config.get("maximum_rows_in_alert_samples_table"),
25,
)
+ if self.maximum_rows_in_alert_samples_table is not None and self.maximum_rows_in_alert_samples_table < 1:
+ raise InvalidArgumentsError(
+ "maximum_rows_in_alert_samples_table must be a positive integer."
+ )Option B — Add a min constraint in the CLI option:
`@click.option`(
"--maximum-rows-in-alert-samples-table",
"-mr",
type=int,
default=25,
+ callback=lambda ctx, param, value: value if value >= 1 else ctx.fail("must be >= 1"),
help="Maximum number of rows to display in a table in alert samples.",
)🤖 Prompt for AI Agents
In `@elementary/monitor/alerts/alert_messages/builder.py` around lines 398 - 417,
Guard against non-positive maximum_rows_in_alert_samples_table by normalizing it
before truncation: compute a safe_max = max(1,
self.config.maximum_rows_in_alert_samples_table) (or treat <=0 as "no
truncation" by using safe_max = None and skipping truncation), then use safe_max
when slicing result_sample and when computing omitted_rows_count = max(0,
len(result_sample) - safe_max); update the truncation branch that uses
result_sample[:self.config.maximum_rows_in_alert_samples_table],
omitted_rows_count, TableBlock.from_dicts, LinesBlock and ItalicTextLineBlock to
reference safe_max so you never produce an empty table or negative
omitted_rows_count for 0/negative config values.
Description
This PR fixes issue #2044 where Teams alerts fail when the payload is too large (typically when there are >25 rows with multiple columns in test result samples).
Changes
maximum_rows_in_alert_samples_tableconfig parameter (default: 25)_get_result_blocks()that:--maximum-rows-in-alert-samples-table(-mr) to customize the limitConfigclass to handle the new parameterDataMonitoringAlertsto pass the config toAlertMessageBuilderHow it works
When test result samples exceed the row limit:
Testing
Added tests for:
Fixes #2044
Summary by CodeRabbit
New Features