Strong Verification failure message can't tell users whether birthdate or gender mismatched

[claude]

Problem

When a Strong Verification attempt fails because the passport data doesn't match the user's profile, we show a single combined message that mentions both date of birth and gender:

Your Strong Verification attempt has failed because the date of birth or gender on your profile does not match the date of birth or sex on your passport. Please contact the support team to update your date of birth or gender, or if your passport sex does not match your gender identity.

Because this message can't tell the user which field actually mismatched, some users contact support confused about why their verification failed (raised in the email copy review in #9150, on app/backend/src/couchers/email/locales/en.json).

Why it's a catch-all today

In app/backend/src/couchers/jobs/handlers.py we only check the combined predicate has_strong_verification(user) and, on failure, emit a single reason:

couchers/app/backend/src/couchers/jobs/handlers.py

Lines 1013 to 1022 in cdeff25

	else:
	notify(
	session,
	user_id=verification_attempt.user_id,
	topic_action=NotificationTopicAction.verification__sv_fail,
	key="",
	data=notification_data_pb2.VerificationSVFail(
	reason=notification_data_pb2.SV_FAIL_REASON_WRONG_BIRTHDATE_OR_GENDER
	),
	)

else:
    notify(
        session,
        user_id=verification_attempt.user_id,
        topic_action=NotificationTopicAction.verification__sv_fail,
        key="",
        data=notification_data_pb2.VerificationSVFail(
            reason=notification_data_pb2.SV_FAIL_REASON_WRONG_BIRTHDATE_OR_GENDER
        ),
    )

has_strong_verification is defined as the AND of the birthdate and gender checks, so by the time we reach the else we've thrown away which one failed:

# couchers/models/verification.py
def has_strong_verification(self, user):
    return self.is_valid & self._raw_birthdate_match(user) & self._raw_gender_match(user)

Good news

The model already exposes the granular checks matches_birthdate(user) and matches_gender(user) (in couchers/models/verification.py), so we can distinguish the cause without new data:

def matches_birthdate(self, user): return self.is_valid & self._raw_birthdate_match(user)
def matches_gender(self, user):    return self.is_valid & self._raw_gender_match(user)

Proposed fix

• In the failure branch, evaluate matches_birthdate / matches_gender separately and pick a more specific SV_FAIL_REASON_* (e.g. wrong birthdate vs. wrong gender; possibly keep the combined reason only for the both-wrong case).
• Add the corresponding reason enum value(s) to the VerificationSVFail proto.
• Split the email/notification copy into separate, targeted messages (the email copy review noted this should be a follow-up, not part of Backend/emails: Review copy before localizing #9150).

Notes / open questions

• @aapeliv has the most context on the Strong Verification flow and whether there are edge cases (e.g. passport_sex == unspecified, the has_passport_sex_gender_exception escape hatch) that should still fall back to the combined message.
• This affects more than just the email — push notifications and any other surface using SV_FAIL_REASON_WRONG_BIRTHDATE_OR_GENDER would need updating too.

Filed from a review discussion in #9150.

[tristanlabelle]

@claude Implement a fix that introduces separate enums for the birthdate and gender mismatches.

[claude]

Claude finished @tristanlabelle's task in 8m 6s —— View job • claude/issue-9174-20260624-2220 • Create PR ➔

---

Task: Separate enums for birthdate vs gender SV failures

• Add SV_FAIL_REASON_WRONG_BIRTHDATE (4) and SV_FAIL_REASON_WRONG_GENDER (5) to the proto enum, keeping the combined reason for the both-wrong case
• Regenerate protos (make protos)
• Update handlers.py failure branch to evaluate matches_birthdate/matches_gender separately and pick the specific reason
• Update push notification rendering (render_push.py) + locale copy
• Update email rendering (emails.py) + locale copy + test_instances
• Add tests for the three failure cases
• Run make format, make mypy
• Commit & push

Summary

Strong Verification failures from a birthdate/gender mismatch used to emit one combined reason, so the user couldn't tell which field was wrong. I introduced two granular reasons and updated the failure branch to choose between them:

birthdate_ok = verification_attempt.matches_birthdate(user)
gender_ok = verification_attempt.matches_gender(user)
if not birthdate_ok and not gender_ok:
    reason = SV_FAIL_REASON_WRONG_BIRTHDATE_OR_GENDER
elif not birthdate_ok:
    reason = SV_FAIL_REASON_WRONG_BIRTHDATE
else:
    reason = SV_FAIL_REASON_WRONG_GENDER

The combined SV_FAIL_REASON_WRONG_BIRTHDATE_OR_GENDER is kept (same field number/meaning) for the both-wrong case, which also covers the escape hatches (passport_sex == unspecified, has_passport_sex_gender_exception) since those make matches_gender pass — so an exception user with a bad birthdate now correctly gets the birthdate-only message.

Files changed

• app/proto/notification_data.proto — two new enum values (4, 5); existing numbers untouched
• app/backend/src/couchers/jobs/handlers.py — pick specific reason in the failure branch
• app/backend/src/couchers/notifications/render_push.py + notifications/locales/en.json — split push copy
• app/backend/src/couchers/email/emails.py + email/locales/en.json — split email copy
• app/backend/src/tests/test_strong_verification.py — new tests for wrong-birthdate, wrong-gender, and both-wrong

Verification

• make mypy ✅ (exhaustiveness checks on the match statements pass)
• make format ✅
• test_dump_emails.py + test_i18n_locales.py ✅ (render every email reason variant incl. the new ones, against locale keys)
• The three new SV integration tests could not be run here: the test DB connection string points at /postgres rather than /testdb, and overriding it required a permission approval that was denied. They'll run in CI.

Notes

• Generated proto files (*/proto/gen, couchers/proto, web/proto) are gitignored in this repo, so only the .proto source is committed; CI regenerates them.
• Only en.json copy was added — other locales fall back to English until translated.
• Front-end/other surfaces consuming the enum get the new values via the regenerated TS proto; no existing value changed.

--- • Branch: claude/issue-9174-20260624-2220