Matrix webhook calls are synchronous with no connect-timeout — worst case ~30s added to a single comment's response time #77

New Issue

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

jared commented

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

Severity: Medium

helpers/NotificationHelper::fire() (~line 22) sets CURLOPT_TIMEOUT, 10 but no CURLOPT_CONNECTTIMEOUT. The call runs inline during ticket create/comment/status-change/assign — a slow-but-not-fully-hung hookshot endpoint can add up to 10 seconds to the user-facing HTTP response for each fire() call.

Impact: Multiple fire() calls can happen sequentially within one request — e.g. api/add_comment.php can fire mention + comment + watcher notifications one after another, each with its own 10s ceiling, so a single comment submission has a worst-case ~30 second added latency if the Matrix homeserver/hookshot is slow to respond (not fully down, just slow — a full connection failure would be caught faster without an explicit connect timeout only if the OS-level connect fails fast, which isn't guaranteed).

Fix: Add CURLOPT_CONNECTTIMEOUT (e.g. 2-3s) alongside the existing total timeout, and/or move notification dispatch off the synchronous request path (a simple fire-and-forget via a queue, or at minimum run the 2-3 sequential fire() calls per request in a way that doesn't stack their timeouts linearly).

**Severity:** Medium `helpers/NotificationHelper::fire()` (~line 22) sets `CURLOPT_TIMEOUT, 10` but no `CURLOPT_CONNECTTIMEOUT`. The call runs inline during ticket create/comment/status-change/assign — a slow-but-not-fully-hung hookshot endpoint can add up to 10 seconds to the user-facing HTTP response for each `fire()` call. **Impact:** Multiple `fire()` calls can happen sequentially within one request — e.g. `api/add_comment.php` can fire mention + comment + watcher notifications one after another, each with its own 10s ceiling, so a single comment submission has a worst-case ~30 second added latency if the Matrix homeserver/hookshot is slow to respond (not fully down, just slow — a full connection failure would be caught faster without an explicit connect timeout only if the OS-level connect fails fast, which isn't guaranteed). **Fix:** Add `CURLOPT_CONNECTTIMEOUT` (e.g. 2-3s) alongside the existing total timeout, and/or move notification dispatch off the synchronous request path (a simple fire-and-forget via a queue, or at minimum run the 2-3 sequential fire() calls per request in a way that doesn't stack their timeouts linearly).

jared added the notifications performance priority/medium 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#77