Skip to content

Commit f012870

Browse files
committed
fix(service-sms): sms/test names the transport that carried it, not "via log"
With the recipient defaulting to the admin's own number, a deployment that configured its SMS transport at boot while the namespace's provider sits at its `log` default now reaches this path from the served form: the live service delivers, and the answer said "via log". Claude-Session: https://claude.ai/code/session_011TdZ8GjixNZFLz1xJD9zzK Co-authored-by: Claude <noreply@anthropic.com>
1 parent cf44de1 commit f012870

3 files changed

Lines changed: 34 additions & 2 deletions

File tree

‎.changeset/24767-settings-test-send-recipient.md‎

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -11,7 +11,7 @@ The Mail and SMS settings pages offer a Send test button and no recipient input,
1111

1212
With no `to` in the request, the test now goes to the person who pressed the button: `mail/test` sends to the caller's own account email and `sms/test` to the caller's own phone number, each read from the caller's own `sys_user` row. A `to` in the request body still wins, as before. When the caller's account has no address or number, or the account cannot be read, the action refuses and says that nothing was sent. A phone number is on an account only where phone sign-in is enabled, so on other deployments "Send test SMS" still needs a `to` in the request body.
1313

14-
`sms/test` no longer reports a send through the log-only transport (the namespace's default `None (log only)` provider) as a success. It answers `ok: false` with severity `warning`, as `mail/test` already does for its log transport.
14+
`sms/test` no longer reports a send through the log-only transport (the namespace's default `None (log only)` provider) as a success. It answers `ok: false` with severity `warning`, as `mail/test` already does for its log transport. When the form names no delivering provider and the transport the deployment configured at boot carries the test, the success message names that transport instead of saying the message went "via log".
1515

1616
**Unchanged.**
1717

‎packages/services/service-sms/src/sms-plugin.test.ts‎

Lines changed: 28 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -186,6 +186,34 @@ describe('SmsServicePlugin', () => {
186186
expect(send).not.toHaveBeenCalled();
187187
expect(result.message).not.toContain('5550006');
188188
});
189+
190+
it('names the deployment\'s transport, not `log`, when the boot-configured one carried the test', async () => {
191+
// A deployment that configured Twilio at boot, with the namespace's
192+
// `provider` still at its `log` default: the live service delivers, so the
193+
// answer must not say the message went "via log".
194+
const fetchImpl = vi.fn(async () => new Response(
195+
JSON.stringify({ sid: 'SM1', status: 'queued' }),
196+
{ status: 201, headers: { 'Content-Type': 'application/json' } },
197+
));
198+
const harness = fakeCtx({
199+
settingsValues: { provider: 'log' },
200+
settingsSources: { provider: 'default' },
201+
});
202+
const plugin = new SmsServicePlugin({
203+
provider: 'twilio',
204+
providerOptions: { accountSid: 'AC1', authToken: 't', from: '+15005550006', fetchImpl },
205+
});
206+
await plugin.init(harness.ctx);
207+
await plugin.start(harness.ctx);
208+
await harness.fireReady();
209+
210+
const result = await harness.actions.get('sms/test')!({
211+
values: { provider: 'log' }, payload: { to: '+15005550009' }, ctx: {},
212+
});
213+
expect(result).toMatchObject({ ok: true, severity: 'info' });
214+
expect(fetchImpl).toHaveBeenCalledTimes(1);
215+
expect(result.message).not.toMatch(/via log\b/);
216+
});
189217
});
190218

191219
describe('SmsServicePlugin — authored-value criterion (#5536)', () => {

‎packages/services/service-sms/src/sms-plugin.ts‎

Lines changed: 5 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -370,10 +370,14 @@ export class SmsServicePlugin implements Plugin {
370370
if (result.status === 'failed') {
371371
return { ok: false, severity: 'error', message: result.error ?? 'Send failed.' };
372372
}
373+
// Name the transport that actually carried it. When the form
374+
// names no delivering provider, the live service did — the one
375+
// the deployment configured at boot, never `log` (refused above).
376+
const via = target === svc ? 'the deployment\'s configured transport' : resolved.provider;
373377
return {
374378
ok: true,
375379
severity: 'info',
376-
message: `Sent test SMS to ${maskPhoneNumber(to)} via ${resolved.provider} (id=${result.messageId ?? result.id}).`,
380+
message: `Sent test SMS to ${maskPhoneNumber(to)} via ${via} (id=${result.messageId ?? result.id}).`,
377381
};
378382
} catch (err: any) {
379383
return { ok: false, severity: 'error', message: err?.message ?? String(err) };

0 commit comments

Comments
 (0)