Failed Matrix webhook posts are logged but never retried — confirm this best-effort design is intentional #78

New Issue

2026-09-01T00:07:13-04:00

jared commented

2026-09-01 00:07:13 -04:00

Severity: Low / informational

helpers/NotificationHelper::fire() (~lines 30-34) logs cURL errors / non-2xx responses via error_log() only, with no retry and no persistent record. If a webhook fails, the underlying DB write (audit_log entry, status change, etc.) has already committed — there's no record anywhere that the Matrix side of that event never went out. There is an existing code comment near notifyWatchers() (~lines 190-192) suggesting this best-effort behavior is intentional.

Flagging for confirmation rather than as a bug: is silent loss of failed notifications acceptable, or should failed webhook posts be queued for retry (e.g. a simple retry table processed by a cron job)? If the current behavior is fine, no action needed beyond this note.

**Severity:** Low / informational `helpers/NotificationHelper::fire()` (~lines 30-34) logs cURL errors / non-2xx responses via `error_log()` only, with no retry and no persistent record. If a webhook fails, the underlying DB write (audit_log entry, status change, etc.) has already committed — there's no record anywhere that the Matrix side of that event never went out. There is an existing code comment near `notifyWatchers()` (~lines 190-192) suggesting this best-effort behavior is intentional. Flagging for confirmation rather than as a bug: is silent loss of failed notifications acceptable, or should failed webhook posts be queued for retry (e.g. a simple retry table processed by a cron job)? If the current behavior is fine, no action needed beyond this note.

jared added the needs-decision notifications priority/low labels 2026-09-08 10:15:48 -04:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: LotusGuild/tinker_tickets#78