Skip to content

fix: default backend exception_class and drop unreachable serializer branch - #142

Open
CuriousLearner wants to merge 1 commit into
masterfrom
fix/backend-error-handling
Open

fix: default backend exception_class and drop unreachable serializer branch#142
CuriousLearner wants to merge 1 commit into
masterfrom
fix/backend-error-handling

Conversation

@CuriousLearner

Copy link
Copy Markdown
Owner

Summary

Two defects in the verification error paths, both found by cross-checking the documentation against running code.

exception_class defaulted to None. BaseBackend.__init__ set self.exception_class = None, and send_security_code_and_generate_session_token catches service.backend.exception_class. A backend that never set the attribute therefore raised TypeError: catching classes that do not inherit from BaseException is not allowed on any send failure, masking the real provider error. None of the custom backend examples in docs/customization.rst, docs/troubleshooting.rst, or docs/configuration.rst set it, so backends written from the documentation hit this. It is now a class attribute defaulting to Exception, so it applies even to backends that do not call super().__init__(). The built-in Twilio and Nexmo backends continue to narrow it to their provider's error type.

The SESSION_TOKEN_INVALID serializer branch was unreachable. validate_security_code returns that status only together with a None verification, and the serializer tested verification is None first, so "Session Token mis-match" could never be returned. The two equivalent conditions are merged into the existing "Security code is not valid" error. Reporting them identically also avoids revealing which of phone_number, session_token, or security_code was rejected. Callers that need to distinguish the cases still get the specific status from verify_security_code().

Docs that promised the unreachable error are corrected, and the serializer error list now includes the brute-force message, which was previously undocumented.

Test plan

  • New test_provider_error_is_logged_when_backend_omits_exception_class builds a backend shaped like the documented examples and asserts the provider error is logged rather than raised. Verified it fails with the old None default.
  • phone_verify/serializers.py goes from 97% to 100% coverage, confirming the removed branch was the only uncovered line.
  • Full suite: 145 passed. Ruff clean.

…branch

BaseBackend left exception_class as None, so a custom backend that never set it
made send_security_code_and_generate_session_token raise 'catching classes that
do not inherit from BaseException is not allowed' instead of logging the
provider error. None of the custom backend examples in the documentation set the
attribute, so backends written from the docs hit this on any send failure.
Default it to Exception on the class, so it applies even when a backend does not
call super().__init__.

The serializer checked 'verification is None' before SESSION_TOKEN_INVALID, but
the backend only returns that status together with a None verification, leaving
the 'Session Token mis-match' branch unreachable. Merge the equivalent
conditions into the existing 'Security code is not valid' error, which also
avoids naming which of phone_number, session_token or security_code was
rejected, and update the docs that promised an error the API never returned.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant