bug: non-Error jQuery events captured by Sentry on CDR page produce 5 noise-fingerprints/day (Sentry MHA/MHD/MHE/MHJ/MHP)

[jorikfon]

Summary

Sentry shows ~5 distinct issue groups every day with <unknown> titles, all originating from /admin-cabinet/call-detail-records/index/ line 7 (library: web-interface, uncaught). Each event reports:

Error: Object captured as exception with keys: isTrigger, jQuery22<digits>

The keys isTrigger and jQuery22… are diagnostic of a jQuery event object — i.e. the value that ends up at window.onerror is a jQuery event, not an Error instance. Sentry's GlobalHandlers integration cannot extract a stack trace from a non-Error value, so each jQuery22<random> cache id produces a new fingerprint and hence a new Sentry issue, polluting the project with noise even though the underlying bug is one.

Sentry footprint (last 24h)

ShortID	Count	First seen	Release
MIKOPBX-MHP	1	2026-05-02T16:54:43Z	2024.1.114
MIKOPBX-MHJ	1	2026-05-02T14:21:31Z	2024.1.114
MIKOPBX-MHE	1	2026-05-02T12:41:17Z	2024.1.114
MIKOPBX-MHD	3	2026-05-02T12:08:44Z	2024.1.114
MIKOPBX-MHA	1	2026-05-02T08:49:47Z	2024.1.114

Same pattern has been emitting steadily on at least one production host running release mikopbx@2024.1.114 (CDR page is the only entry point).

Latest event (anonymised)

type:    Error
value:   Object captured as exception with keys: isTrigger, jQuery22405411215834297335
file:    /admin-cabinet/call-detail-records/index/ : 7
release: mikopbx@2024.1.114
library: web-interface
handled: no

Stack frame is a single inline-script line on the rendered CDR page — not a named source file — which is consistent with an onerror-type capture rather than a try/catch rethrow.

Likely root cause

Either:

1. Somewhere in the CDR page's JS a throw <event> is happening synchronously inside a jQuery event callback (jQuery 3+ marks user-triggered events with isTrigger=3), or
2. A jQuery .fail(handler) / .ajaxError(handler) is calling Sentry.captureException(eventOrXhr) (or rethrowing) with a non-Error.

The bug isn't a runtime crash for the user — every fingerprint has count=1 and users=1 per group — but it floods the Sentry project with low-signal noise because each new jQuery22<cacheId> produces a new group in Sentry.

Suggested fix

Two complementary changes:

1. Filter out non-Error captures in sites/admin-cabinet/assets/js/src/main/sentry-error-logger.js — drop the events where hint.originalException is not an Error:

beforeSend(event, hint) {
    const ex = hint && hint.originalException;
    // Filter jQuery events / non-Error throwables — they produce a new
    // Sentry fingerprint on every page load due to jQuery's per-instance
    // cache id, which masks real bugs.
    if (ex && typeof ex === 'object' && !(ex instanceof Error)
        && 'isTrigger' in ex) {
        return null; // drop
    }
    if (event.exception) {
        const error = ex;
        if (error && error.message && error.message.length > 0) {
            // ...existing report dialog code...
        }
    }
    return event;
}

2. Track down the actual throw <jQueryEvent> or captureException(<jQueryEvent>) site on the CDR page (call-detail-records-index.js and any CDR-specific module loaded with it — likely an audio player wrapper around <audio id="audio-player-${record.id}">, since MHA-MHP cluster tightly with the play() AbortError reported separately as MIKOPBX-MH8). Replace any rethrow of a jQuery event with throw new Error(JSON.stringify({ type: ev.type, target: ev.target?.id })); so Sentry produces one stable group per cause.

Notes

• Counterpart on the same page: MIKOPBX-MH8 (AbortError: play() request was interrupted by end of playback). That one is a real Error and groups correctly — separate issue (browser-level audio quirk, can be left alone or filtered).
• All five occurrences come from a single end-user host and a single MikoPBX install; the pattern fires every time the CDR page is opened on that host. If we just filter at SDK level, root cause stays hidden — recommend doing both.