This is a follow-up for your previous findings, i wanted to use this project but i get blocked by issues which are known in the codebase but not getting any action such as:
Billing/Files transactional outbox. Billing publishes InvoiceIssuedIntegrationEvent directly via the in-memory bus instead of the outbox (Files does the same with no consumer yet). The fix needs a BuildingBlocks/Eventing redesign: the outbox infra resolves a single IOutboxStore/OutboxDispatcher, and Identity is the only module wired to it — registering a second module makes IOutboxStore resolve ambiguously and would risk breaking Identity's working outbox. That is protected, high-blast-radius framework work that shouldn't land without a dedicated change (keyed stores / IEnumerable + multi-context dispatch). The in-memory synchronous path works today, so this is an architectural follow-up, not a release blocker.
#1273
This doesn't align with your Agent documentation which states one outbox per dbcontext.
https://github.com/fullstackhero/dotnet-starter-kit/blob/6f381db433dbf317f5a1bdf993df3ffbc99768af/.agents/skills/add-integration-event/SKILL.md#step-2--publish-via-the-outbox-source-handler
This is the blocker i get from Claude:
The outbox is silently broken for both new modules — and for Identity's existing one.
AddEventingForDbContext() does a plain services.AddScoped<IOutboxStore, EfCoreOutboxStore>() — non-keyed. Since it's called three times now (Identity, Tickets, MyModule, in that load order), .NET's DI resolves IOutboxStore to whichever was registered last — EfCoreOutboxStore — everywhere in the app. But only IdentityDbContext actually maps the OutboxMessage/InboxMessage entities and has migrations creating those tables (IdentityDbContext.cs:66-67); MyModuleDbContext and TicketsDbContext never do. I confirmed this directly — grep for OutboxMessage in both new DbContexts returns nothing, and no MyModule/Tickets migration creates those tables.
Consequences, none caught by any test (every test substitutes IOutboxStore):
Creating an MyModule maintenance record now throws (Set() on a context that never modeled that entity), and since the create handler deliberately has no separate SaveChangesAsync, the record isn't even persisted.
The status-sync publisher fails the same way, silently (swallowed by DomainEventsInterceptor).
Regression outside this feature: Identity's token generation and user registration now resolve the wrong outbox store too.
This needs a real decision, not just a fix: either map OutboxMessage/InboxMessage into both new DbContexts (plus migrations) and resolve the store per-context explicitly (keyed services or concrete injection instead of ambient IOutboxStore), or drop both new AddEventingForDbContext calls and share Identity's outbox (cheaper, but then the create handler's "atomic, one transaction" comment becomes false and needs rewriting, since the outbox write would hit a different context than the one holding the new entity). These have real tradeoffs — which do you want?
This is a follow-up for your previous findings, i wanted to use this project but i get blocked by issues which are known in the codebase but not getting any action such as:
#1273
This doesn't align with your Agent documentation which states one outbox per dbcontext.
https://github.com/fullstackhero/dotnet-starter-kit/blob/6f381db433dbf317f5a1bdf993df3ffbc99768af/.agents/skills/add-integration-event/SKILL.md#step-2--publish-via-the-outbox-source-handler
This is the blocker i get from Claude:
The outbox is silently broken for both new modules — and for Identity's existing one.
AddEventingForDbContext() does a plain services.AddScoped<IOutboxStore, EfCoreOutboxStore>() — non-keyed. Since it's called three times now (Identity, Tickets, MyModule, in that load order), .NET's DI resolves IOutboxStore to whichever was registered last — EfCoreOutboxStore — everywhere in the app. But only IdentityDbContext actually maps the OutboxMessage/InboxMessage entities and has migrations creating those tables (IdentityDbContext.cs:66-67); MyModuleDbContext and TicketsDbContext never do. I confirmed this directly — grep for OutboxMessage in both new DbContexts returns nothing, and no MyModule/Tickets migration creates those tables.
Consequences, none caught by any test (every test substitutes IOutboxStore):
Creating an MyModule maintenance record now throws (Set() on a context that never modeled that entity), and since the create handler deliberately has no separate SaveChangesAsync, the record isn't even persisted.
The status-sync publisher fails the same way, silently (swallowed by DomainEventsInterceptor).
Regression outside this feature: Identity's token generation and user registration now resolve the wrong outbox store too.
This needs a real decision, not just a fix: either map OutboxMessage/InboxMessage into both new DbContexts (plus migrations) and resolve the store per-context explicitly (keyed services or concrete injection instead of ambient IOutboxStore), or drop both new AddEventingForDbContext calls and share Identity's outbox (cheaper, but then the create handler's "atomic, one transaction" comment becomes false and needs rewriting, since the outbox write would hit a different context than the one holding the new entity). These have real tradeoffs — which do you want?