QRun-IO/qbit-marketing
3
0 Fork 0
Code Issues 1 Pull Requests 2 Actions Packages Projects Releases 7 Wiki Activity

Use a qbit-email API, not its internals (architecture G1) #13

New Issue
Closed
opened 2026-10-14 13:17:51 +00:00 by KofTwentyTwo · 0 comments
KofTwentyTwo commented 2026-10-14 13:17:51 +00:00 (Migrated from github.com)
Copy link
Copy source

The qbit-email integration (#11) added com.kingsrook.qbits:qbit-email as an optional dependency. email/QbitEmailTransport and MarketingRuntime import its internals:

  • EmailRuntime and EmailQBitConfig;
  • outbox.EmailService, EmailRequest, EmailSendResult and EmailCategory;
  • metadata.EmailTables;
  • support.SystemWrites.

This is the same coupling that architecture review QRun-IO/qqq#1150 flagged in F4 (easypost to alerts) and F5 (marketing to assistant). The enforced guardrails (qbit-build-parent 2.1.0, G1) reject it.

Fix:

  • qbit-email publishes a small API, either a com.kingsrook.qbits.email.api package or a qbit-email-api artifact, holding at least the send request and result, the category, and an "is the outbox available" probe. Alternatively, it registers as a core QQQ messaging provider, so marketing calls core and needs no qbit-email type at all.
  • Marketing then depends only on that API.

Until then: qbit-marketing#12 allow-lists qbit-email and its packages explicitly in qbit.guardrails.allowedQbitArtifacts/allowedApiPackages, pointing at this issue. The exception is visible and tracked.

The qbit-email integration (#11) added `com.kingsrook.qbits:qbit-email` as an optional dependency. `email/QbitEmailTransport` and `MarketingRuntime` import its internals: - `EmailRuntime` and `EmailQBitConfig`; - `outbox.EmailService`, `EmailRequest`, `EmailSendResult` and `EmailCategory`; - `metadata.EmailTables`; - `support.SystemWrites`. This is the same coupling that architecture review QRun-IO/qqq#1150 flagged in F4 (easypost to alerts) and F5 (marketing to assistant). The enforced guardrails (qbit-build-parent 2.1.0, G1) reject it. **Fix:** - qbit-email publishes a small API, either a `com.kingsrook.qbits.email.api` package or a `qbit-email-api` artifact, holding at least the send request and result, the category, and an "is the outbox available" probe. Alternatively, it registers as a core QQQ messaging provider, so marketing calls core and needs no qbit-email type at all. - Marketing then depends only on that API. **Until then:** qbit-marketing#12 allow-lists `qbit-email` and its packages explicitly in `qbit.guardrails.allowedQbitArtifacts`/`allowedApiPackages`, pointing at this issue. The exception is visible and tracked.
Sign in to join this conversation.
No Branch/Tag Specified
Labels
Clear labels
architecture
Architecture review: coupling, cohesion, UI API
 bug
Something isn't working
 dependencies
documentation
Improvements or additions to documentation
 duplicate
This issue or pull request already exists
 enhancement
New feature or request
 github_actions
Pull requests that update GitHub Actions code
 good first issue
Good for newcomers
 help wanted
Extra attention is needed
 invalid
This doesn't seem right
 java
Pull requests that update java code
 question
Further information is requested
 release:rc
Merging this develop PR cuts the next release candidate
 secuurity
wontfix
This will not be worked on
No labels architecture
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
forge-recovery (Forge Recovery) james.maes (James Maes)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: QRun-IO/qbit-marketing#13