spikerj/spikersoft-issues
1
0
Fork 0
Code Issues 196 Pull Requests Actions Packages Projects Releases Wiki Activity

Twilio Verify worker handlers read wrong config key (Twilio:VerificationServiceSid vs Twilio:VerifyServiceSid) #261

New Issue
Closed
opened 2026-06-26 20:00:46 +00:00 by spikerj · 2 comments
spikerj commented 2026-06-26 20:00:46 +00:00
Owner
Copy Link
Copy Source

Problem

The notifications worker dispatches SendVerificationCodeCommand / VerifyCodeCommand to MediatR handlers in SpikerSoft.Workers.Notifications/Handlers/. Those handlers load the Verify service SID from the wrong configuration key:

_verificationServiceSid = _configuration["Twilio:VerificationServiceSid"]; // wrong

But appsettings.json (both SpikerSoft.Api and SpikerSoft.EventHandlers.Notifications) and the canonical TwilioVerifyService use Twilio:VerifyServiceSid:

"Twilio": { "VerifyServiceSid": "VA..." }

So request.VerificationServiceSid ?? _verificationServiceSid resolves to null, and both handlers short-circuit with VERIFICATION_SERVICE_NOT_CONFIGURED. This silently masks the #260 fix: the API now correctly dispatches the commands to the worker, but the worker can't find the SID and fails the send/check.

Fix

Standardize on Twilio:VerifyServiceSid (the key already present in appsettings and used by TwilioVerifyService):

  • SpikerSoft.Workers.Notifications/Handlers/SendVerificationCodeCommandHandler.cs
  • SpikerSoft.Workers.Notifications/Handlers/VerifyCodeCommandHandler.cs
  • Update the four unit-test config mocks that referenced the old key.

Note: the command property VerificationServiceSid and the Mongo audit field of the same name are left as-is — only the config key lookup changes.

Acceptance

  • With Twilio:VerifyServiceSid configured, the worker's verification send/check use the SID instead of returning VERIFICATION_SERVICE_NOT_CONFIGURED.
  • Backend-only change; no SPA change.

Follow-up to #260 (it called this out as adjacent cleanup).

## Problem The notifications worker dispatches `SendVerificationCodeCommand` / `VerifyCodeCommand` to MediatR handlers in `SpikerSoft.Workers.Notifications/Handlers/`. Those handlers load the Verify service SID from the **wrong** configuration key: ```csharp _verificationServiceSid = _configuration["Twilio:VerificationServiceSid"]; // wrong ``` But `appsettings.json` (both `SpikerSoft.Api` and `SpikerSoft.EventHandlers.Notifications`) and the canonical `TwilioVerifyService` use `Twilio:VerifyServiceSid`: ```jsonc "Twilio": { "VerifyServiceSid": "VA..." } ``` So `request.VerificationServiceSid ?? _verificationServiceSid` resolves to **null**, and both handlers short-circuit with `VERIFICATION_SERVICE_NOT_CONFIGURED`. This silently masks the #260 fix: the API now correctly dispatches the commands to the worker, but the worker can't find the SID and fails the send/check. ## Fix Standardize on `Twilio:VerifyServiceSid` (the key already present in appsettings and used by `TwilioVerifyService`): - `SpikerSoft.Workers.Notifications/Handlers/SendVerificationCodeCommandHandler.cs` - `SpikerSoft.Workers.Notifications/Handlers/VerifyCodeCommandHandler.cs` - Update the four unit-test config mocks that referenced the old key. Note: the command property `VerificationServiceSid` and the Mongo audit field of the same name are left as-is — only the **config key** lookup changes. ## Acceptance - With `Twilio:VerifyServiceSid` configured, the worker's verification send/check use the SID instead of returning `VERIFICATION_SERVICE_NOT_CONFIGURED`. - Backend-only change; no SPA change. Follow-up to #260 (it called this out as adjacent cleanup).
spikerj commented 2026-06-26 20:24:12 +00:00
Author
Owner
Copy Link
Copy Source

Scope expanded in PR #21 after checking the deploy/env wiring: found a second gate. The worker's verify handlers check Twilio:Enabled first (defaulting to false when absent) and would return TWILIO_DISABLED before ever reaching the SID. The worker's appsettings.json Twilio block was missing Enabled (the API's has "Enabled": true).

Added to PR #21:

  • "Enabled": true in SpikerSoft.EventHandlers.Notifications/appsettings.json Twilio block (matches the API).
  • Documented Twilio__Enabled in deploy/docker-stack.yml (defaults true via appsettings; set false to disable per env).

Still required at deploy time (server-side per-service stack /mnt/infrastructure/spikersoft-notifications): Twilio__AccountSid, Twilio__AuthToken, Twilio__VerifyServiceSid.

Scope expanded in PR #21 after checking the deploy/env wiring: found a second gate. The worker's verify handlers check `Twilio:Enabled` first (defaulting to `false` when absent) and would return `TWILIO_DISABLED` before ever reaching the SID. The worker's `appsettings.json` Twilio block was missing `Enabled` (the API's has `"Enabled": true`). Added to PR #21: - `"Enabled": true` in `SpikerSoft.EventHandlers.Notifications/appsettings.json` Twilio block (matches the API). - Documented `Twilio__Enabled` in `deploy/docker-stack.yml` (defaults true via appsettings; set false to disable per env). Still required at deploy time (server-side per-service stack `/mnt/infrastructure/spikersoft-notifications`): `Twilio__AccountSid`, `Twilio__AuthToken`, `Twilio__VerifyServiceSid`.
spikerj commented 2026-06-27 19:17:25 +00:00
Author
Owner
Copy Link
Copy Source

Resolved. Fixed in spikersoft-backend PR #21 (merged to master, commit ede0fa6): the worker verify handlers now read Twilio:VerifyServiceSid (matching the configured key) instead of Twilio:VerificationServiceSid. Closing.

Resolved. Fixed in spikersoft-backend PR #21 (merged to `master`, commit `ede0fa6`): the worker verify handlers now read `Twilio:VerifyServiceSid` (matching the configured key) instead of `Twilio:VerificationServiceSid`. Closing.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
agentic
Actionable surfaced by the agentic architecture & security review
 bug
Something is not working
 duplicate
This issue or pull request already exists
 enhancement
New feature
 help wanted
Need some help
 invalid
Something is wrong
 question
More information is needed
 sonarqube
Code quality issue surfaced by SonarQube (bug / code smell)
 wontfix
This won't be fixed
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
spikerj (Joseph Spiker)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: spikerj/spikersoft-issues#261