PostgreSQL data type

[xiaoma111-stop]

Could you please change the data type for the PostgreSQL field? VARCHAR(255) isn't quite sufficient, as some alert messages exceed 255 characters; could it be changed to TEXT?

[Aidaho12]

Thanks for reporting this.

Could you please provide a little more information so we can change the correct field?

• Which PostgreSQL table/column is hitting the VARCHAR(255) limit?
• What is the exact PostgreSQL error message?
• Which IncidentRelay version are you currently running?
• If possible, please provide an example alert payload that triggers the error. Sensitive values can be removed.

Several alert-related fields that may contain long text are already stored as TEXT, so I'd like to identify the exact column before changing the schema.

[xiaoma111-stop]

Upstream issue: IncidentRelay 2.2.0 — long alert fields exceed VARCHAR(255) and silently disable all alert notifications Filed against IncidentRelay upstream. Sanitized: passwords, hostnames and tokens removed or replaced. 1. Environment Item Value IncidentRelay version *2.2.0* (image ghcr.io/roxy-wi/incidentrelay:2.2.0) Database *PostgreSQL* (not SQLite) ORM peewee — *no runtime string-length validation*; CharField(max_length=255) is only used in the generated DDL Deployment Kubernetes; alerts are delivered by Keep through the Alertmanager integration endpoint Upstream source Keep, which concatenates the names/values of all alerts in an incident into a single title/description 2. Symptom and impact (severe) When an alert arrives: 1. Route matching, rotation selection, assignee selection and the alert_group insert all succeed; 1. The very next write raises DataError and *the whole processing pipeline aborts*; 1. Result: *no notification is delivered at all* for that alert — even though the notification channel itself works (the "send test notification" button in the UI reaches the group fine); 1. Worse, a *half-written record* is left behind: alert_group exists but the child alert row is missing. In the UI this shows up as empty labels / payload ({}), and clicking *Resolve* returns *404* because the backend cannot find the resource to act on. 3. Evidence: processing trace (expandable on the alert detail page) 4. Exact error (PostgreSQL / peewee) Bottom of the stack — this confirms it is an *INSERT* (with RETURNING), not an UPDATE: *What we could not determine:* the exact table/column. The failing statement is not logged, and the INSERT that failed is precisely the one carrying the raw payload — so *the payload is lost with the failure and cannot be inspected afterwards* (see suggestion 3 in section 7). 5. All VARCHAR(255) columns found during triage alert: title, severity, source, status, priority_slug, previous_status, maintenance_behavior, external_id, dedup_key, group_key alert_group: title, severity, source, status, previous_status, priority_slug, maintenance_behavior, notification_reason, group_key_hash alertnotification: provider, external_message_id, external_channel_id, last_event_type, provider_status alertnotificationevent: event_type, provider_status, digit, action alertevent: event_type alert_group_shelve: source (Everything else in the alert path is already TEXT/JSONB.) 6. Reproduction steps Prerequisite: a *PostgreSQL instance with the stock schema* — if columns have already been widened to TEXT it will not reproduce. Post an alert whose title/description/value are long (this is what Keep produces when it aggregates several alerts into one incident): Expected result: the API may return success, but opening the alert shows #14 Alert processing failed / DataError in the processing trace, and the notification channel receives nothing. *To pin down the column:* inflate only one field at a time (first only alertname, then only description, then only annotations.value) and see which one triggers the error. We cannot do this ourselves anymore because our production columns have already been widened. 7. Suggested fixes (any of these) 1. *Widen the columns that carry external text to TEXT* — alert title, description and value all come from an upstream system and their length is not under IncidentRelay's control. At minimum alert.title and alert_group.title should be widened (on PostgreSQL varchar → text is a fully backward-compatible widening). 1. *Truncate to the column width and log a warning* instead of letting the whole pipeline raise. Today a single long field makes the alert *lose its notification capability entirely*, which is far worse than a truncated title. 1. *Persist the raw payload when processing fails* (e.g. write it into a TEXT column or log it with the error). Current behaviour — insert fails, payload is lost, nothing can be diagnosed afterwards — is exactly why we could not name the column. 1. (Optional) Since peewee's CharField(max_length=255) only affects DDL, if the length constraint is kept, validate/truncate explicitly on the write path. 8. Ruled out - The notification channel works (the UI "send test notification" reaches the group). - Routing, rotation, assignee selection and group creation all work. - Short alerts are completely fine; *only over-long fields trigger this*, which makes it look intermittent. Pavel Loginov ***@***.***> 于2026年9月24日周四 00:57写道：

…

*Aidaho12* left a comment (roxy-wi/IncidentRelay#97) <#97 (comment)> Thanks for reporting this. Could you please provide a little more information so we can change the correct field? - Which PostgreSQL table/column is hitting the VARCHAR(255) limit? - What is the exact PostgreSQL error message? - Which IncidentRelay version are you currently running? - If possible, please provide an example alert payload that triggers the error. Sensitive values can be removed. Several alert-related fields that may contain long text are already stored as TEXT, so I'd like to identify the exact column before changing the schema. — Reply to this email directly, view it on GitHub <#97?email_source=notifications&email_token=BT6QRGVHQ6U5NUKPBDCXCHT5QP6JJA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKNZZHEYDOMZUHAZ2M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#issuecomment-5799073483>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BT6QRGVBJQENCOA3LTJFXB35QP6JJAVCNFSNUABGKJSXA33TNF2G64TZHMYTEMRUGIZTMNRTHA5US43TOVSTWNJVGU2DMMRVGU3TFILWAI> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/BT6QRGSAJXWAE2JJMELZART5QP6JJA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKNZZHEYDOMZUHAZ2M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KUZTPN52GK4S7NFXXG> and Android <https://github.com/notifications/mobile/android/BT6QRGTTZCLIFO2AJFYCX6T5QP6JJA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKNZZHEYDOMZUHAZ2M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2K4ZTPN52GK4S7MFXGI4TPNFSA>. Download it today! You are receiving this because you authored the thread.Message ID: <roxy-wi/IncidentRelay/issues/97/5799073483 ***@***.***>

[Aidaho12]

Thank you for information, It closed here 9b4e4d1