[DEBT] AddMessagingServicesCore duplicates the per-pattern registration helpers extracted in #1399

[dlrivada]

Type

• Failing tests
• Missing tests
• Code quality (warnings, analyzers)
• Performance optimization
• Refactoring needed
• Documentation gap
• Incorrect implementation
• Other

Description

PR #1399 (#1333) split AddMessagingServices and AddOutboxInboxSagaSchedulingServices in src/Encina.Messaging/MessagingServiceCollectionExtensions.cs into small per-pattern helpers (RegisterTransactions, RegisterRoutingSlips, RegisterRecoverability, RegisterContentRouter, RegisterScatterGather, RegisterSoftDeleteServices and the Outbox, Inbox, Saga and Scheduling helpers) to pass the CRAP gate. AddMessagingServicesCore in the same file, used by the ADO.NET tenancy extensions, still carries its own inline copies of the same conditional blocks, so the two paths can drift again, which is the defect class #1333 fixed.

Location

src/Encina.Messaging/MessagingServiceCollectionExtensions.cs, AddMessagingServicesCore.

Current Behavior

AddMessagingServicesCore duplicates the registration blocks that the new Register* helpers now own. It also re-checks flags that RegisterSoftDeleteServices, RegisterModuleIsolationServices and RegisterReadWriteSeparationServices now check themselves; this is harmless but redundant.

Expected Behavior

AddMessagingServicesCore calls the same Register* helpers, so every registration path shares one implementation per pattern.

Root Cause

#1399 kept its scope to the methods the CRAP gate flagged; AddMessagingServicesCore was not in the diff, so it kept the older inline form.

Proposed Fix

Replace the inline blocks in AddMessagingServicesCore with calls to the existing helpers, drop the redundant outer checks, and keep the ADO.NET tenancy DI tests green (together with #1398, which adds ValidateOnBuild DI tests for the ADO.NET and Dapper providers).

Priority

• High - Blocks functionality or causes failures in production
• Medium - Should be fixed before 1.0 release
• Low - Nice to have, can be deferred

Effort Estimate

• Small (< 1 hour)
• Medium (1-4 hours)
• Large (> 4 hours)

Related Issues

• [BUG] MongoDB never registers InboxPipelineBehavior; EF Core and MongoDB never register ISagaRunner/ISagaNotFoundDispatcher #1333 - EF Core and MongoDB messaging registration drift
• [TEST] ADO.NET and Dapper DI tests do not prove the messaging registrations with ValidateOnBuild #1398 - ADO.NET and Dapper DI tests with ValidateOnBuild