Page MenuHomePhabricator

[native] handle database operations errors in reducer
ClosedPublic

Authored by kamil on Feb 13 2023, 6:08 AM.
Tags
None
Referenced Files
Unknown Object (File)
Mon, Dec 9, 9:01 PM
Unknown Object (File)
Tue, Dec 3, 1:17 PM
Unknown Object (File)
Sun, Dec 1, 1:06 PM
Unknown Object (File)
Oct 29 2024, 1:29 PM
Unknown Object (File)
Sep 30 2024, 1:19 AM
Unknown Object (File)
Sep 30 2024, 1:19 AM
Unknown Object (File)
Sep 30 2024, 1:19 AM
Unknown Object (File)
Sep 30 2024, 1:19 AM
Subscribers

Details

Summary

Follow up to D5672.
If there will be an error while processing store operations we want to note this in secure store and kill app, after opening again database will be recreated.

This code introduces CommCoreModule method and calls it when needed.

Test Plan

Test functionality:

  1. Cause error in store operation - app should be killed
  2. Open again - new database should be created

Diff Detail

Repository
rCOMM Comm
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

kamil held this revision as a draft.
kamil published this revision for review.Feb 13 2023, 6:35 AM
native/cpp/CommonCpp/NativeModules/CommCoreModule.cpp
1070 ↗(On Diff #22414)

Generally we have a convention that database operations (not only those that touch database directly) are executed on database thread, and relevant CommCoreModule methods return promises that are handled by JS. I consider it beneficial to stick to that convention. It was my mistake as a reviewer not to request another DatabaseManager methods to be called asynchronously on the C++ in your previous diffs. I would introduce this change in this differential and create follow up task on Linear to make other calls to DatabaseManager asynchronous on the C++ side as well.

native/cpp/CommonCpp/NativeModules/CommCoreModule.cpp
1070 ↗(On Diff #22414)

We discussed this IRL, sharing context for reliability:

  • database thread is for running things connected to the database but this is not the case, flipping flag will do not have anything in common with SQLite or any other query executor, and might cause some actions (like clearSensitiveData) which touch database instance and will be scheduled on database thread
  • it's okay to use blocking calls in this case, not promise because we need information on whether database is okay or not before doing anything on it
  • we expect this function to be called right before killing app or at the very beginning of running the app, and things it changes will be addressed before doing anything with the database

so it's okay to leave this as it is

This revision is now accepted and ready to land.Feb 22 2023, 5:58 AM