Repository navigation
fix(api): answer an SMS guard refusal with its status - #396
Merged
Merged
Conversation
The customer and driver login, creation-code and forgot-password endpoints wrap their SMS send in a catch-all, so a refusal from the guard (a RuntimeException) was flattened into the generic 400 send error, or into the email fallback, and an app could neither explain it nor back off. The refusal now reaches the caller with the status it carries: 422 for a number that can never be texted, 429 with Retry-After for a cooldown or budget, 423 while texting is paused. Login still falls back to email when the account has an address; the refusal is the answer only when nothing else can carry the code.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Follow-up to #393 / #395. The customer and driver
login-with-sms,request-creation-codeandforgot-passwordendpoints wrap their SMS send in a catch-all, so a refusal from the SMS guard (SmsBlockedException, aRuntimeException) was flattened into the generic 400 send error or into the email fallback. An app could neither explain the refusal to the person nor back off.The refusal now reaches the caller with the status it carries, as the storefront endpoints already do:
422429+Retry-After423Login keeps its email fallback: with an email on file the code goes by email and the response says
method: email; the refusal is the answer only when nothing else can carry the code.Changes
Api/v1/CustomerController:requestCreationCodeandforgotPasswordcatchSmsBlockedExceptionbefore the generic catch;loginWithPhoneremembers why the text failed and answers with it when the email fallback is unavailable or also fails. Two small helpers,smsBlockedResponse()andsendFailureResponse(), live in the controller (a shared trait in another namespace would break the test harnesses' namespacedresponse()fakes).Api/v1/DriverController: same forloginWithPhoneandforgotPassword.ApiCustomerControllerContractsTest(423 on creation code withRetry-After, 429 on login without email, email fallback on login with email, 422 on forgot-password),ApiDriverPasswordContractsTest(429 on forgot-password),DriverControllerAuthFlowsTest(email fallback, then 423 withRetry-Afteronce the email is gone, driven by a Twilio fake that throws the refusal).Validation
php -landphp-cs-fixer --dry-runon the five files are clean. The suite was not run locally (the Pest runner does not work on this machine); CI stays blocked on thefleetbase/core-api ^1.6.69tag as on #395.Docs: fleetbase/fleetbase.io#128 and fleetbase/postman#66 describe this behaviour.