[Bug] Notifications worker crashes on SendVerificationCodeCommand — IMongoClient is never registered #263

New Issue

2026-06-27T03:14:55Z

spikerj commented

2026-06-27 03:14:55 +00:00

Summary

Every SendVerificationCodeCommand processed by the Notifications worker fails at handler activation because SendVerificationCodeCommandHandler constructor-injects MongoDB.Driver.IMongoClient, but the Notifications worker never registers MongoDB. The command is therefore never handled and 2FA/verification SMS via Twilio Verify is broken end-to-end.

Evidence (Production docker logs)

[22:11:08 ERR] [Production/SpikerSoft.EventHandlers.Notifications] SendVerificationCodeCommand processing failed (correlation=44bd5aab-cf19-41ce-9be4-21568e82034e)
System.InvalidOperationException: Unable to resolve service for type 'MongoDB.Driver.IMongoClient' while attempting to activate 'SpikerSoft.Business.Domain.Twilio.Commands.SendVerificationCode.SendVerificationCodeCommandHandler'.
   ...
   at SpikerSoft.EventHandlers.Notifications.Services.NotificationsRpcConsumerHostedService.OnMessageReceivedAsync(...) in /src/SpikerSoft.EventHandlers.Notifications/Services/NotificationsRpcConsumerHostedService.cs:line 164

Root cause

SendVerificationCodeCommandHandler requires IMongoClient (used to write an audit record to the twilio_verifications collection).
The Notifications worker's Program.cs builder chain has no .WithMongoDB() call, the worker is not attached to the mongo overlay network, and no Mongo__ConnectionString is supplied. So IMongoClient is unresolvable and MediatR throws when activating the handler.

Impact

Phone verification codes are never sent from the Notifications worker.
The failure is caught and the RabbitMQ message is acked, so callers get a Success=false envelope rather than a retry.

Fix (Option B — keep full audit logging)

Give the Notifications worker real MongoDB access so the twilio_verifications audit write succeeds:

Add .WithMongoDB(includeDbContext: false) to the worker's builder chain (only IMongoClient is needed, not the EF SpikerDbContext).
Add a Mongo section (connection string + database) to the worker's appsettings.json, matching the book-management / codeexecution workers.
Attach the notifications service to the external mongo overlay network in deploy/docker-stack.yml so mongo-router is DNS-resolvable.

Health checks intentionally remain includeMongoDb: false: the audit write is best-effort (failures are swallowed in LogVerificationRequest), so Mongo availability should not flip the worker's liveness.

## Summary Every `SendVerificationCodeCommand` processed by the Notifications worker fails at handler activation because `SendVerificationCodeCommandHandler` constructor-injects `MongoDB.Driver.IMongoClient`, but the Notifications worker never registers MongoDB. The command is therefore never handled and 2FA/verification SMS via Twilio Verify is broken end-to-end. ## Evidence (Production docker logs) ``` [22:11:08 ERR] [Production/SpikerSoft.EventHandlers.Notifications] SendVerificationCodeCommand processing failed (correlation=44bd5aab-cf19-41ce-9be4-21568e82034e) System.InvalidOperationException: Unable to resolve service for type 'MongoDB.Driver.IMongoClient' while attempting to activate 'SpikerSoft.Business.Domain.Twilio.Commands.SendVerificationCode.SendVerificationCodeCommandHandler'. ... at SpikerSoft.EventHandlers.Notifications.Services.NotificationsRpcConsumerHostedService.OnMessageReceivedAsync(...) in /src/SpikerSoft.EventHandlers.Notifications/Services/NotificationsRpcConsumerHostedService.cs:line 164 ``` ## Root cause - `SendVerificationCodeCommandHandler` requires `IMongoClient` (used to write an audit record to the `twilio_verifications` collection). - The Notifications worker's `Program.cs` builder chain has **no** `.WithMongoDB()` call, the worker is **not** attached to the `mongo` overlay network, and no `Mongo__ConnectionString` is supplied. So `IMongoClient` is unresolvable and MediatR throws when activating the handler. ## Impact - Phone verification codes are never sent from the Notifications worker. - The failure is caught and the RabbitMQ message is acked, so callers get a `Success=false` envelope rather than a retry. ## Fix (Option B — keep full audit logging) Give the Notifications worker real MongoDB access so the `twilio_verifications` audit write succeeds: 1. Add `.WithMongoDB(includeDbContext: false)` to the worker's builder chain (only `IMongoClient` is needed, not the EF `SpikerDbContext`). 2. Add a `Mongo` section (connection string + database) to the worker's `appsettings.json`, matching the `book-management` / `codeexecution` workers. 3. Attach the `notifications` service to the external `mongo` overlay network in `deploy/docker-stack.yml` so `mongo-router` is DNS-resolvable. Health checks intentionally remain `includeMongoDb: false`: the audit write is best-effort (failures are swallowed in `LogVerificationRequest`), so Mongo availability should not flip the worker's liveness. ## Related Continues the Twilio Verify worker-routing chain from #260 and #261.

spikerj added the bug label 2026-06-27 03:14:55 +00:00

spikerj referenced this issue

2026-06-27 03:23:10 +00:00

[Bug] Twilio SMS config-key mismatch — handlers read Twilio:PhoneNumber, but appsettings + deploy docs use Twilio:FromNumber (dead MessagingServiceSid) #264

spikerj commented

2026-06-27 03:28:22 +00:00

Resolved in spikersoft-backend PR #22 (merged to master, commit 80b3ec7). Registered MongoDB in the Notifications worker via .WithMongoDB(includeDbContext: false), added the Mongo section to the worker appsettings.json, and attached the service to the mongo overlay network (backend deploy/docker-stack.yml). The authoritative per-service stack in spikersoft-infrastructure was also updated to join the mongo network (commit 61bd5d0) so mongo-router is reachable in production. IMongoClient now resolves and the twilio_verifications audit write works. Closing.

Resolved in spikersoft-backend PR #22 (merged to `master`, commit 80b3ec7). Registered MongoDB in the Notifications worker via `.WithMongoDB(includeDbContext: false)`, added the `Mongo` section to the worker `appsettings.json`, and attached the service to the `mongo` overlay network (backend `deploy/docker-stack.yml`). The authoritative per-service stack in spikersoft-infrastructure was also updated to join the `mongo` network (commit 61bd5d0) so `mongo-router` is reachable in production. `IMongoClient` now resolves and the `twilio_verifications` audit write works. Closing.

spikerj closed this issue

2026-06-27 03:28:32 +00:00

spikerj referenced this issue

2026-07-13 20:20:07 +00:00

[Backend][MinIO] Replace API static-file media serving with S3-backed delivery (epic #413) #528

spikerj referenced this issue

2026-07-13 20:33:04 +00:00

[Backend][MinIO] Replace API static-file media serving with S3-backed delivery (epic #413) #528

Sign in to join this conversation.