mirror of
https://github.com/fosrl/pangolin.git
synced 2026-07-17 07:04:36 -05:00
[PR #3148] [MERGED] fix(audit-logs): route request audit log reads through logsDb #34632
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
📋 Pull Request Information
Original PR: https://github.com/fosrl/pangolin/pull/3148
Author: @bishnubista
Created: 5/25/2026
Status: ✅ Merged
Merged: 5/25/2026
Merged by: @oschwartz10612
Base:
main← Head:fix-audit-log-replica-routing📝 Commits (1)
817e848fix(audit-logs): route request audit log reads through logsDb📊 Changes
2 files changed (+14 additions, -14 deletions)
View changed files
📝
server/routers/auditLogs/queryRequestAnalytics.ts(+5 -5)📝
server/routers/auditLogs/queryRequestAuditLog.ts(+9 -9)📄 Description
Community Contribution License Agreement
By creating this pull request, I grant the project maintainers an unlimited,
perpetual license to use, modify, and redistribute these contributions under any terms they
choose, including both the AGPLv3 and the Fossorial Commercial license terms. I
represent that I have the right to grant this license for all contributed content.
Description
Route the read paths in
server/routers/auditLogs/queryRequestAuditLog.tsandserver/routers/auditLogs/queryRequestAnalytics.tsthroughlogsDbinstead ofprimaryLogsDb, matching the existing private audit log routes (queryActionAuditLog,queryAccessAuditLog,queryConnectionAuditLogall already uselogsDb).In Postgres deployments configured with read replicas via
withReplicas(server/db/pg/logsDriver.ts), this lets high-volume audit log reads use the replica pool instead of contending with writes on the primary. No-op on SQLite wherelogsDb === primaryDb.Why not also rewrite the facet queries?
While here, I benchmarked a candidate rewrite for the
// TODO: SOMEONE PLEASE OPTIMIZE THIS!!!!!atqueryRequestAuditLog.ts:246. Replacing the six parallel `selectDistinct` queries with a single `UNION ALL` over six `GROUP BY ... LIMIT 500` arms is 48-61% slower on SQLite at 100k / 300k / 1M rows (20 runs per impl per size):`EXPLAIN QUERY PLAN` shows each grouped arm does `USE TEMP B-TREE FOR GROUP BY` — every distinct value is materialized before `LIMIT` truncates. The current DISTINCT+LIMIT short-circuits via hash dedup with early exit, which wins for the low-cardinality dropdown shape this endpoint produces. The long-term fix is likely a materialized facets table refreshed by a background job, not a query-shape rewrite.
How to test?
🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.