improvement(outbox): load handler modules only for the event types a run will process

[waleedlatif1]

Summary

• process-outbox statically imported all 18 outbox handler modules, so every run loaded Stripe, the file parsers, react-email, the webhook provider registry, the block registry and more even when nothing was due. Its static graph drops from 5,718 to 794 modules (stripe, pdf-lib, mammoth, @aws-sdk, better-auth, next, … → 0)
• New lib/core/outbox/handlers.ts declares OUTBOX_HANDLER_GROUPS ({ events, load: () => import(...) }, in the old spread order). processOutboxEvents now takes these groups: after discovering ready event types it imports, in parallel, only the groups that serve one, before any claim — so timeoutMs comes from the real handler and import time never runs inside a lease or handler window
• A group whose import fails leaves its event types pending (no attempt spent, other types keep processing), and the run then fails after maintenance with an error naming those types — today a broken handler module crashes every run and blocks all event types; now delivery continues and the failure stays loud. Types in no group still take the existing missing-handler path
• Event-type constants that lived in heavy handler modules moved to light sibling modules (same string values; every importer repointed, no re-exports); a few inline literals became named constants. processOutboxEventById and its callers are unchanged

Type of Change

• Improvement

Testing

• handlers.test.ts: no event type in two groups; each group's loaded handler keys equal its declared events; every export const *OutboxHandlers map in the app is covered by the registry (catches a dropped or never-registered group)
• service.test.ts / service.integration.ts run through the lazy path: only due groups load; a failed import leaves its types unclaimed and reported, others process, the next run imports again; the pre-claim deadline uses the loaded handler's timeoutMs; unknown types still retry/dead-letter as before. processor.test.ts: maintenance completes, then the run fails naming unloaded types
• Each guard shown red by reverting it (drop a group/event, import after claiming, treat a failed import as a missing handler, memoize rejections, load every group, drop unknown types, remove the final throw)
• Root bun run test (3,287 app files), bun run test:integration lib/core/outbox/service.integration.ts, bun run lint, bun run type-check, bun run check:audits (unused-exports baseline shrunk for the moved constants), bun run docs-manifest:check — green

Checklist

• Code follows project style guidelines
• Self-reviewed my changes
• Tests added/updated and passing (new tests pass the test-audit authoring gate)
• No new warnings introduced
• I confirm that I have read and agree to the terms outlined in the Contributor License Agreement (CLA)

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
docs	Ready	Preview	Oct 7, 2026 8:04am UTC

[cubic-dev-ai]

All reported issues were addressed across 83 files

_{Fix all with cubic | Turn on auto-fix | Re-trigger cubic}

[greptile-apps]

Confidence Score: 5/5

[High risk] Refactors outbox event type constants into separate files.

The PR appears safe to merge; no new actionable issues remain.

What we checked:

• Document events still match: Both event strings stay unchanged. The enqueue functions and knowledgeDocumentProcessingOutboxHandlers use the same constants from processing-events.ts.

Summary

The PR loads outbox handler modules only when their event types are ready. It loads them before claiming events, leaves failed groups pending, and reports failures after maintenance.

• The latest changes move enterprise and document event constants into dependency-free files without changing their values.
• No new actionable issues or repository-rule violations were found.
• The earlier, unnumbered PostgreSQL coverage finding is addressed: service.integration.ts checks unchanged pending rows, healthy delivery, and recovery on the next run.
• Tests were inspected, not executed during this review.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart TD
  A[Discover ready event types] --> B[Load matching handler groups]
  B --> C{Group loaded?}
  C -->|Yes| D[Check handler time window]
  D --> E[Claim and process events]
  C -->|No| F[Leave its events pending]
  E --> G[Run maintenance]
  F --> G
  G --> H{Any failed loads?}
  H -->|Yes| I[Fail run with event type names]
  H -->|No| J[Return results]

Loading

_{Reviews (3) · Last reviewed commit: "improvement(outbox): source enterprise a..." · Reviewed by Greptile}

[waleedlatif1]

@greptile

[waleedlatif1]

@cubic-dev-ai review this PR

[cubic-dev-ai]

@cubic-dev-ai review this PR

@waleedlatif1 I have started the AI code review. It will take a few minutes to complete.

[cubic-dev-ai]

All reported issues were addressed across 100 files

<sub>Reply with feedback, questions, or to request a fix.

Fix all with cubic | Turn on auto-fix | Re-trigger cubic</sub>

[waleedlatif1]

@greptile

[waleedlatif1]

@cubic-dev-ai review this PR

[cubic-dev-ai]

@cubic-dev-ai review this PR

@waleedlatif1 I have started the AI code review. It will take a few minutes to complete.

[cubic-dev-ai]

No issues found across 110 files

Confidence score: 5/5

• Automated review surfaced no issues in the provided summaries.
• No files require special attention.

_{Turn on auto-fix | Re-trigger cubic}