[fix] allow long threshold expr when binding many monitors - #4330
Open
orangeCatDeveloper wants to merge 8 commits into
Open
[fix] allow long threshold expr when binding many monitors#4330orangeCatDeveloper wants to merge 8 commits into
orangeCatDeveloper wants to merge 8 commits into
Conversation
orangeCatDeveloper
force-pushed
the
fix/issue-4171-expr-length
branch
from
August 17, 2026 12:13
a5a8100 to
b31d988
Compare
Binding monitors appends an equals(__instance__, ...) clause per monitor to the threshold expr, so the 2048-char limit capped bindings at ~30. Widen expr to a lob with a 65535 validation cap (V182).
orangeCatDeveloper
force-pushed
the
fix/issue-4171-expr-length
branch
from
August 18, 2026 06:22
b31d988 to
69547ff
Compare
Aias00
approved these changes
Aug 23, 2026
Aias00
left a comment
Contributor
There was a problem hiding this comment.
Review: allow long threshold expr when binding many monitors
Clean, well-migrated fix for #4171 (binding >~30 monitors to one rule failed validation).
What's good
AlertDefine.expris widened from@Size(max=2048) @Column(length=2048)to@Lobwith a@Size(max=65535)validation cap — the same pattern the codebase already uses forNoticeTemplate.content. Previously valid input stays valid; the new 65535 cap still rejects runaway payloads.expris admin-authored config, so this widens no new trust boundary.- Migrations
V182for all three vendors are correct and idempotent:- MySQL: a stored procedure guarded by
INFORMATION_SCHEMA(table exists, column exists, andDATA_TYPE != 'longtext') thenALTER ... MODIFY COLUMN expr LONGTEXT— matching the existingV172/V180style, so re-running is a no-op. - PostgreSQL:
ALTER COLUMN expr TYPE TEXT— lossless widen. - H2:
ALTER COLUMN expr CLOB.
- MySQL: a stored procedure guarded by
- Tests pin both directions: a 76-monitor-binding expr (>2048 chars) validates cleanly, and a 65536-char expr fails with exactly one violation on
expr(the custom message was intentionally dropped so the default localized hibernate-validator message is used). - Backward compatible: existing rows are widened losslessly, and the PR's e2e trace confirms a 2296-char expr now persists intact.
Non-blocking note
- MySQL
longtextcan hold far more than 65535 chars, but the@Size(65535)validation is the effective ceiling, so there's no practical over-allocation concern.
No blocking issues. Approve.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #4171
Binding more than ~30 monitors to one alert rule fails with a validation error, because each bound monitor appends an
equals(__instance__, "...")clause (~65 chars) to the thresholdexpr, and the field was capped at 2048 characters — 2048 / 65 ≈ 30 bindings.The fix widens
AlertDefine.exprfrom@Size(2048)/@Column(2048)to@Lobwith a@Size(65535)validation cap — the same pattern the codebase already uses forNoticeTemplate.content. MigrationV182alters the column on all three vendors (mysqllongtextwith an INFORMATION_SCHEMA idempotency guard matching V172/V180, postgresqlTEXT, h2CLOB); widening is lossless for existing rows. The custom validation message was deliberately dropped so the default hibernate-validator message stays localized.Backward compatible: previously valid input remains valid, the new 65535 cap still rejects runaway payloads, and
expris admin-authored config so no new trust boundary.Verified end-to-end against a real backend (fresh H2,
Successfully applied 7 migrations ... now at version v182):