PM QA 7620

[pm-dimagi]

Product Description

Fixed the crash for the second time recovery or signup for connectid

Technical Summary

The user is getting crash when he signup or recover account every alternative time the db was not getting cleared

StackTrace
Caused by net.sqlcipher.database.SQLiteException: error code 8: attempt to write a readonly database
at net.sqlcipher.database.SQLiteStatement.native_execute(SQLiteStatement.java)
at net.sqlcipher.database.SQLiteStatement.execute(SQLiteStatement.java:61)
at net.sqlcipher.database.SQLiteDatabase.insertWithOnConflict(SQLiteDatabase.java:2227)
at net.sqlcipher.database.SQLiteDatabase.insertOrThrow(SQLiteDatabase.java:2103)
at org.commcare.models.database.SqlStorage.write(SqlStorage.java:633)
at org.commcare.connect.database.ConnectUserDatabaseUtil.storeUser(ConnectUserDatabaseUtil.java:46)
at org.commcare.fragments.connectId.ConnectIDSignupFragment$4.processSuccess(ConnectIDSignupFragment.java:380)
at org.commcare.connect.network.ApiConnectId$1.onResponse(ApiConnectId.java:261)
at retrofit2.DefaultCallAdapterFactory$ExecutorCallbackCall$1.lambda$onResponse$0(DefaultCallAdapterFactory.java:89)
at android.os.Handler.handleCallback(Handler.java:938)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loopOnce(Looper.java:226)
at android.os.Looper.loop(Looper.java:313)
at android.app.ActivityThread.main(ActivityThread.java:8669)
at java.lang.reflect.Method.invoke(Method.java)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:571)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1135)

Feature Flag

https://dimagi.atlassian.net/browse/QA-7620

cross-request: dimagi/commcare-core#1455

Safety Assurance

Safety story

Automated test coverage

QA Plan

Labels and Review

• Do we need to enhance the manual QA test coverage ? If yes, the "QA Note" label is set correctly
• Does the PR introduce any major changes worth communicating ? If yes, the "Release Note" label is set and a "Release Note" is specified in PR description.
• Risk label is set correctly
• The set of people pinged as reviewers is appropriate for the level of risk of the change

[coderabbitai]

📝 Walkthrough

Walkthrough

The changes remove the static synchronization mechanism from the ConnectUserDatabaseUtil class. Specifically, the static LOCK object and the corresponding synchronized (LOCK) blocks have been eliminated from the getUser, storeUser, and forgetUser methods. Additionally, a call to ConnectDatabaseHelper.teardown() has been inserted in the forgetUser method after the deletion of user data, which appears to be aimed at cleanup or resource deallocation. These modifications simplify the code by removing explicit thread-safety locking while introducing a new operation during user removal.

Sequence Diagram(s)

sequenceDiagram
    participant Caller as Client
    participant Util as ConnectUserDatabaseUtil
    participant Helper as ConnectDatabaseHelper

    Caller->>Util: forgetUser()
    Util->>Util: Delete user data from database
    Util->>Helper: teardown()
    Util-->>Caller: Return / Handle exceptions

Loading

Possibly related PRs

• QA-7332 || User Creation Issue & OTP remove Digit issue  #2919: Involves modifications related to user data management with a direct invocation of ConnectDatabaseHelper.forgetUser(requireContext()) in the ConnectIDSignupFragment, linking to changes in the ConnectUserDatabaseUtil class.

Suggested reviewers

• OrangeAndGreen

---

📜 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 5abaedc and a9d21ca.

📒 Files selected for processing (1)

• app/src/org/commcare/connect/database/ConnectUserDatabaseUtil.java (1 hunks)

🧰 Additional context used

🧬 Code Definitions (1)

app/src/org/commcare/connect/database/ConnectUserDatabaseUtil.java (1)

app/src/org/commcare/connect/database/ConnectDatabaseHelper.java (1)

• ConnectDatabaseHelper (27-117)

🔇 Additional comments (2)

app/src/org/commcare/connect/database/ConnectUserDatabaseUtil.java (2)

11-68:

Details

✅ Verification successful

Consider thread safety implications of removing synchronization.

According to the AI summary, this change removed a static LOCK object and synchronized blocks from the database methods. While the addition of teardown() helps with resource cleanup, removing synchronization could potentially introduce thread safety issues if these methods are called concurrently from different threads.

Is there a reason synchronization was deemed unnecessary? If these methods are only called from the UI thread or if ConnectDatabaseHelper has its own synchronization mechanism (as suggested by the connectDbHandleLock in the relevant code snippet), this might be safe. Otherwise, consider whether additional protection against concurrent access is needed.

---

🏁 Script executed:

#!/bin/bash
# Check where these methods are called from to determine if concurrent access is possible

# First look for calls to getUser
echo "Calls to getUser:"
rg "ConnectUserDatabaseUtil\.getUser\(" --glob "**/*.java" -A 2 -B 2

# Then look for calls to storeUser
echo -e "\nCalls to storeUser:"
rg "ConnectUserDatabaseUtil\.storeUser\(" --glob "**/*.java" -A 2 -B 2

# Then look for calls to forgetUser 
echo -e "\nCalls to forgetUser:"
rg "ConnectUserDatabaseUtil\.forgetUser\(" --glob "**/*.java" -A 2 -B 2

# Check if ConnectDatabaseHelper has internal synchronization for database operations
echo -e "\nChecking ConnectDatabaseHelper for synchronization mechanisms:"
rg "synchronized" app/src/org/commcare/connect/database/ConnectDatabaseHelper.java -A 5 -B 5

Length of output: 23627

---

Thread Safety Verification: No Additional Synchronization Needed
After reviewing the call sites and confirming that all invocations of getUser, storeUser, and forgetUser predominantly occur on the UI thread (or via the main looper) and noting that ConnectDatabaseHelper already ensures access is properly synchronized via its internal connectDbHandleLock, the removal of the explicit synchronization in ConnectUserDatabaseUtil appears acceptable. Please ensure that if there’s any future change that might allow these methods to be called concurrently on background threads, the risk is reassessed.

---

57-57:

Details

✅ Verification successful

Addition of database teardown addresses resource cleanup issue.

Adding ConnectDatabaseHelper.teardown() is a good fix for ensuring database connections are properly closed after user deletion. This likely addresses the core issue mentioned in the PR where the database wasn't being properly cleared between attempts, causing crashes on alternating account recovery or signup attempts.

The teardown method properly closes the database connection and sets the reference to null, which should prevent resource leaks and ensure a clean state for subsequent operations.

---

🏁 Script executed:

#!/bin/bash
# Check if there are any other calls to ConnectDatabaseHelper.teardown() in the codebase
# or if this is the only place ensuring database cleanup during user removal

rg -A 1 -B 1 "ConnectDatabaseHelper\.teardown\(\)" --glob "**/*.java"

Length of output: 656

---

Database connection cleanup validated; ensure thread safety remains robust.

The addition of ConnectDatabaseHelper.teardown() in ConnectUserDatabaseUtil.java effectively addresses the resource cleanup problem identified in the PR and aligns with how cleanup is handled in test code (as seen in CommCareTestApplication.java). This change should remedy the crash on subsequent account recovery or signup attempts by properly closing and nullifying the database connection.

A couple of points for further consideration:

• The removal of explicit synchronization in methods like getUser, storeUser, and forgetUser relies on internal locking in ConnectDatabaseHelper (via connectDbHandleLock). Please verify that these methods are indeed only invoked in contexts (e.g., the UI thread) where concurrent access won’t introduce race conditions.
• It’s advisable to run multi-threaded tests if there's any chance these methods might be accessed concurrently.

✨ Finishing Touches

• 📝 Generate Docstrings

---

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

🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

• Review comments: Directly reply to a review comment made by CodeRabbit. Example:
  • I pushed a fix in commit <commit_id>, please review it.
  • Generate unit testing code for this file.
  • Open a follow-up GitHub issue for this discussion.
• Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
  • @coderabbitai generate unit testing code for this file.
  • @coderabbitai modularize this function.
• PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
  • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
  • @coderabbitai read src/utils.ts and generate unit testing code.
  • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
  • @coderabbitai help me debug CodeRabbit configuration file.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (Invoked using PR comments)

• @coderabbitai pause to pause the reviews on a PR.
• @coderabbitai resume to resume the paused reviews.
• @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
• @coderabbitai full review to do a full review from scratch and review all the files again.
• @coderabbitai summary to regenerate the summary of the PR.
• @coderabbitai generate docstrings to generate docstrings for this PR.
• @coderabbitai resolve resolve all the CodeRabbit review comments.
• @coderabbitai plan to trigger planning for file edits and PR creation.
• @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
• @coderabbitai help to get help.

Other keywords and placeholders

• Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
• Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
• Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (.coderabbit.yaml)

• You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
• Please see the configuration documentation for more information.
• If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

• Visit our Documentation for detailed information on how to use CodeRabbit.
• Join our Discord Community to get help, request features, and share feedback.
• Follow us on X/Twitter for updates and announcements.

[shubham1g5]

is this the primary fix here or removal of synchronized blocks ?

[pm-dimagi]

the primary fix is this one lock dosent help because connectdatabse is not getting null

[shubham1g5]

can we add the crash stacktrace here in PR description