Added analytics event for PersonalID account lockout (on Backup Code …

[OrangeAndGreen]

Added an analytics event when the user is informed that their PersonalID account has been locked on the Backup Code page.

[coderabbitai]

📝 Walkthrough

Walkthrough

A single analytics event reporting call is added to the handleAccountLockout method in PersonalIdBackupCodeFragment.java. When account lockout is handled, the system now reports a configuration failure event via FirebaseAnalyticsUtil.reportPersonalIdConfigurationFailure with the parameter AnalyticsParamValue.START_CONFIGURATION_LOCKED_ACCOUNT_FAILURE. The existing lockout handling logic remains unchanged.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~3 minutes

This change involves a single, straightforward addition of one analytics reporting call to an existing method with no modifications to control flow, business logic, or public interfaces. The addition is localized, low-risk, and requires minimal verification beyond confirming the correct analytics event and parameter are being used.

Pre-merge checks and finishing touches

❌ Failed checks (2 warnings)

Check name	Status	Explanation	Resolution
Description Check	⚠️ Warning	The pull request description is a single sentence that provides only a high-level overview of the change. The description template requires multiple structured sections including Product Description, Technical Summary (with link to ticket and rationale), Feature Flag, Safety Assurance (with safety story, test coverage, and QA plan), and Labels and Review checklist. The provided description is missing all of these required sections, lacks any link to the ticket or supporting documentation, contains no information about the rationale or design decisions, and includes no discussion of safety considerations or test coverage. This represents a significant deviation from the expected template structure and depth.	The pull request description should be expanded to follow the repository template. At minimum, add a Technical Summary section with a link to the ticket that prompted this change and explain the rationale, a Safety Assurance section describing how the change was tested and why it is safe, an Automated test coverage section documenting related tests, and a QA Plan section. If this change has no visible user-facing effects, the Product Description section may be deleted as indicated in the template. Complete the Labels and Review checklist to ensure all required labels are properly set on the PR.
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	You can run @coderabbitai generate docstrings to improve docstring coverage.

✅ Passed checks (1 passed)

Check name	Status	Explanation
Title Check	✅ Passed	The title "Added analytics event for PersonalID account lockout (on Backup Code …" directly describes the main change in the pull request. The raw summary confirms that an analytics event was added to the handleAccountLockout method in PersonalIdBackupCodeFragment.java. The title is specific, concise, and clearly communicates the primary change without vague language or unnecessary detail. It accurately reflects the changeset and would help teammates understand the purpose of this code change when scanning the git history.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch lockout_analytics

---

📜 Recent review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 0be4d61 and 58e259d.

📒 Files selected for processing (1)

• app/src/org/commcare/fragments/personalId/PersonalIdBackupCodeFragment.java (1 hunks)

🧰 Additional context used

🧬 Code graph analysis (1)

app/src/org/commcare/fragments/personalId/PersonalIdBackupCodeFragment.java (2)

app/src/org/commcare/google/services/analytics/FirebaseAnalyticsUtil.java (1)

• FirebaseAnalyticsUtil (43-608)

app/src/org/commcare/google/services/analytics/AnalyticsParamValue.java (1)

• AnalyticsParamValue (7-194)

🔇 Additional comments (1)

app/src/org/commcare/fragments/personalId/PersonalIdBackupCodeFragment.java (1)

259-266: LGTM! Analytics event correctly captures account lockout.

The addition properly tracks the locked account scenario with an appropriate analytics event. The placement is logical—after logging the recovery failure but before user feedback—and complements the existing logRecoveryResult call without duplication.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[shubham1g5]

Not blocking on my review given we might need to get this in the release quite soon.

[shubham1g5]

@OrangeAndGreen I see this is also being logged by handleCommonSignupFailures ? and I am confused what path is the right one that gets triggered on locked account ?

[OrangeAndGreen]

Yeah, we still have plans to clean this up but in the meantime it gets caught in two ways. One is the case in this fragment where the API call to verify backup code succeeds whether correct/incorrect/locked, but the session is updated to indicate which is the case (via dbKey, sessionFailureCode, and attemptsLeft).
In any other API call the server can also fail and return a code indicating that the account is locked, which we handle with a common error handler. In practice I think that failure only ever happens on the confirm_otp call, although it could be on other calls later in the workflow as well.