Drizzle puts the full SQL text in its error message, so Sentry files one recurring transport failure as a new issue per query

Replicator's Sentry project collected twelve separate issues between August and November 2026, on tables including blog_article, jwks, chat_session and short_url. Each looked new, and each was triaged and resolved on its own. They shared one cause: the libSQL HTTP connection dropping.

Drizzle wraps a failed statement as Failed query: select ... from "table" ..., with the full SQL in the message. Sentry groups on that text, so every distinct query in flight when the connection dropped became its own issue. The daily digest listed unresolved issues, and nothing on them said this was the same problem again. Triaging that digest is what surfaced the pattern.

The fix is in scrubSentryEvent, which now gives this class one shared fingerprint. Two conditions keep it narrow, and both are mutation-tested. The event must carry drizzle's Failed query: wrapper and a transport-level cause, so the AI gateway's and Vercel Blob's own fetch failed errors keep their groups. Any SQL-level signature, such as SQLITE_CONSTRAINT or no such column, vetoes the regrouping. A genuine UNIQUE constraint failed error (REPLICATOR-2Y) carried the same prefix as the transients, and it keeps its own issue. The transport signatures came from real captured exception chains: SocketError: other side closed, ConnectTimeoutError, a TLS socket disconnect, and a libSQL SERVER_ERROR carrying an HTTP 5xx. The change applies to new events. Existing issues keep their old fingerprints.

Rule: when an error message embeds variable text such as SQL or parameters, the error tracker will split one cause into many issues. Fingerprint on the cause, and keep real SQL errors out of the transient group.

Receipt: Replicator v3.326.0 (commit e06509b7; src/lib/utils/scrubSentryEvent.ts, tests/lib/utils/scrubSentryEvent.test.ts).