Summary
Re-alert notifications fail to fire when Suspendible Notification is enabled because 16 email-send conditionals in thold_functions.php redundantly check $thold_data['acknowledgment'] == ''. This check duplicates the upstream $suspend_notify guard (lines 2375, 2505, 2950, 3172, 3325), which already correctly evaluates the acknowledgment state. When $suspend_notify allows re-alert (because the threshold is still breached), the downstream acknowledgment == '' check incorrectly blocks the send.
Root Cause
The current pattern at every send site:
if (trim($alert_emails) != '' && $thold_data['acknowledgment'] == '') {The $suspend_notify flag is set upstream in each evaluation branch and correctly handles the acknowledgment state. The downstream acknowledgment == '' guard inverts the upstream decision for re-alerts.
Affected Code
16 conditionals in thold_functions.php follow this pattern:
if (trim($alert_emails) != '' && $thold_data['acknowledgment'] == '') {
if (trim($warning_emails) != '' && $thold_data['acknowledgment'] == '') {Send sites include alert paths, warning paths, and restoral paths.
Proposed Fix
Extract a thold_has_recipients() helper that centralizes the send guard without the redundant acknowledgment check:
/**
* Returns true if a notification should be sent to the given email list.
*
* The acknowledgment state is intentionally NOT checked here -- it is already
* evaluated upstream via $suspend_notify (see thold_check_threshold). Repeating
* the check here incorrectly blocks re-alerts under Suspendible Notification.
*
* @param string $emails Comma-separated recipient list.
* @return bool
*/
function thold_has_recipients(string $emails): bool {
return trim($emails) !== '';
}All 16 call sites become:
if (thold_has_recipients($alert_emails)) {
if (thold_has_recipients($warning_emails)) {Verification Notes
- The restoral path conditionals (lines ~2693, 2745, 2850, 2860, 3533) also carry the check. Verify these are inside
!$suspend_notify blocks before sweeping -- restoral notifications may have different $suspend_notify semantics.
- The
$suspend_notify upstream guards at lines 2375, 2505, 2950, 3172, 3325 already correctly handle acknowledgment == 'on' by setting $suspend_notify = false.
Related
Summary
Re-alert notifications fail to fire when Suspendible Notification is enabled because 16 email-send conditionals in
thold_functions.phpredundantly check$thold_data['acknowledgment'] == ''. This check duplicates the upstream$suspend_notifyguard (lines 2375, 2505, 2950, 3172, 3325), which already correctly evaluates the acknowledgment state. When$suspend_notifyallows re-alert (because the threshold is still breached), the downstreamacknowledgment == ''check incorrectly blocks the send.Root Cause
The current pattern at every send site:
The
$suspend_notifyflag is set upstream in each evaluation branch and correctly handles the acknowledgment state. The downstreamacknowledgment == ''guard inverts the upstream decision for re-alerts.Affected Code
16 conditionals in
thold_functions.phpfollow this pattern:Send sites include alert paths, warning paths, and restoral paths.
Proposed Fix
Extract a
thold_has_recipients()helper that centralizes the send guard without the redundant acknowledgment check:All 16 call sites become:
Verification Notes
!$suspend_notifyblocks before sweeping -- restoral notifications may have different$suspend_notifysemantics.$suspend_notifyupstream guards at lines 2375, 2505, 2950, 3172, 3325 already correctly handleacknowledgment == 'on'by setting$suspend_notify = false.Related