concurrency-auditor C-2: every queue.add(...) site previously enqueued
without a stable jobId, so a double-dispatch (webhook retry, double-
click on Send, scheduler tick collision) would create two queue jobs
and the downstream worker would deliver twice. BullMQ rejects a
duplicate jobId while the original is still queued or active, so a
stable per-entity key gives at-most-once semantics naturally.
Added jobIds across all 10 enqueue sites:
- email send-invoice → `send-invoice:<invoiceId>`
- notifications invoice-overdue-notify → keyed per UTC day so dupes
collapse intra-day but tomorrow's run can re-notify if unpaid
- export gdpr-export → keyed on the exportId (unique per request)
- webhooks deliver (3 sites: dispatch, retry, test) → keyed on the
webhook_deliveries row UUID
- maintenance expense-dedup-scan → keyed on expenseId
- notifications send-notification-email → keyed on notification id
- email send-inquiry-confirmation → keyed on interestId (1 per
submission)
- email send-inquiry-sales-notification → keyed on interestId+email
(1 per recipient per submission)
- reports generate-report → keyed on the generated_reports row id
Pure refactor — no UX impact. Closes the BullMQ dedup gap that was
the second half of the concurrency-auditor's CRITICAL-tier findings.
Test fixture update: gdpr-export integration test now asserts the
jobId option on the queue.add call.
Tests 1315/1315.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Admin-editable subject overrides at /admin/email-templates were no-ops
for 6 of 8 templates — only portal_activation and portal_reset called
loadSubjectOverride. Added a shared resolveSubject() helper and wired
it into the missing senders:
- crm_invite + portal_invite_resend (crm-invite.service.ts)
- inquiry_client_confirmation (email worker via portId on job payload)
- inquiry_sales_notification (email worker via portId on job payload)
- residential_inquiry_client_confirmation (residential-inquiries route)
- residential_inquiry_sales_alert (residential-inquiries route)
The inquiry email worker payloads now carry portId + portName so the
worker can resolve the per-port override; producers in inquiry-
notifications.service.ts pass them through.
1175/1175 vitest passing.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Replaces per-row fan-out with grouped queries / inArray pre-fetches
across the five dashboard + cron hotspots flagged in the audit
(MED §13 / HIGH §11–14):
* reminders.processFollowUpReminders — was 3 round trips per
enabled-and-due interest. Now: filter in JS, single clients
bulk-fetch, single reminders bulk-insert, single interests
bulk-update, one summary socket emit. 1k due interests: 6 round
trips total instead of 3000+.
* portal.getClientInvoices — was a full-table scan filtered in JS.
Now an inArray push-down on lower(billingEmail) + defensive
limit(100). After 12mo this would have been the worst portal
endpoint.
* interest-scoring.calculateBulkScores — was 6N round trips
(1 redis + 1 findFirst + 4 counts per interest). Now 4 grouped
count queries on the port's interest set + a single redis pipeline
to refresh the cache. 1k interests: ~7 round trips.
* document-reminders.processReminderQueue — was 5N round trips per
cron tick (port + template + lastReminder + pendingSigners + send
per doc). Now hoists port + per-type template map + grouped
lastReminder + bulk pendingSigners; per-row work collapses to a
Map.get and the documenso send. 500 docs: ~7 round trips.
* inquiry-notifications.sendInquiryNotifications — was sequential
createNotification + emailQueue.add per recipient inside a public
POST. Now Promise.all'd; a 20-user port stops blocking the public
inquiry POST on ~80 round trips.
Test status: 1168/1168 vitest, tsc clean.
Refs: docs/audit-comprehensive-2026-05-05.md HIGH §§11–14 (auditor-I
Issues 1–4) + MED §13 (auditor-I Issue 5).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
