-
Notifications
You must be signed in to change notification settings - Fork 260
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(sdk): Add Client:cross_process_store_locks_holder_name()
#4224
Conversation
6ff7493
to
b9bd58f
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, but we should wait until someone can verify if we need the 'default' name.
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #4224 +/- ##
==========================================
+ Coverage 84.87% 84.90% +0.02%
==========================================
Files 274 274
Lines 29719 29716 -3
==========================================
+ Hits 25225 25231 +6
+ Misses 4494 4485 -9 ☔ View full report in Codecov by Sentry. |
On iOS, the holder has to be different across the two different processes. This is the value that allows the app deciding who's holding onto the lock; so the main app would have to use one value, and any extension (notification service extension aka NSE, share extension) would have to use a different value uniquely identifying the service. (The cross-process lock key has to be the same across all processes, though — otherwise processes will coordinate using different entries in the database.) |
b9bd58f
to
8169ad1
Compare
@bnjbvr Yes, I'm aware of that, but I'm wondering if we should use the holder name from the In |
c3e831a
to
f7c700b
Compare
This patch adds `ClientInner::cross_process_store_locks_holder_name` and its public method `Client::cross_process_store_locks_holder_name`. This patch also adds `ClientBuilder::cross_process_store_locks_holider_name` to configure this value.
…ere. See the Changelog Section to get the details. Changelog: `Client::cross_process_store_locks_holder_name` is used everywhere: - `StoreConfig::new()` now takes a `cross_process_store_locks_holder_name` argument. - `StoreConfig` no longer implements `Default`. - `BaseClient::new()` has been removed. - `BaseClient::clone_with_in_memory_state_store()` now takes a `cross_process_store_locks_holder_name` argument. - `BaseClient` no longer implements `Default`. - `EventCacheStoreLock::new()` no longer takes a `key` argument. - `BuilderStoreConfig` no longer has `cross_process_store_locks_holder_name` field for `Sqlite` and `IndexedDb`.
…t::cross_process_store_locks_holder_name`. This patch removes the `process_id` argument from `EncryptionSyncService::new()` and replaces it by `Client::cross_process_store_locks_holder_name`. The “process ID” is set when the `Client` is converted into another `Client` tailore for notification in `NotificationClient` with `Client::notification_client` which now has a new `cross_process_store_locks_holder_name` argument.
…_refresh_crypto_lock`. This patch simplifies a little the `ClientBuilder` API: * `enable_cross_process_refresh_lock` is removed * `enable_oidc_refresh_crypto_lock` + `set_session_delegate` must be used instead.
f7c700b
to
71b7f7f
Compare
PR is ready for another round of review. Complement Crypto is failing, because I've changed the public FFI API. I can disable Complement Crypto quickly, I'm already working on a patch. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The new changes LGTM, thanks.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Otherwise, it all appears reasonable to me and a nice tidy-up 👏
This patch continues to simplification of the `matrix_sdk_ffi::Client`. The constructor can receive a `enable_oidc_refresh_lock: bool` instead of `cross_process_refresh_lock_id: Option<String>`, which was a copy of `matrix_sdk::Client::cross_process_store_locks_holder_name`. Now there is a single boolean to indicate whether `Oidc::enable_cross_process_refresh_lock` should be called or not. If it has to be called, it is possible to re-use `matrix_sdk::Client::cross_process_store_locks_holder_name`. Once again, there is a single place to read this data, it's not copied over different semantics.
71b7f7f
to
4f95712
Compare
We use cross-process store locks in 2 places now: in crypto, and in the event cache. The idea of this PR is to create a common place to define the cross-process store locks holder name.
This PR is twofold. First it creates
Client::cross_process_store_locks_holder_name()
, and second it uses this value for theEventCacheStoreLock
.This PR does not modify the crypto store lock for the moment. I don't know if it has to use the default/common holder name for the moment or not (ping @poljar, @pixlwave).This PR also updatesNotificationClient
to automatically configure the client to use a new holder name, which is used byEncryptionSyncService
to lock the crypto store accordingly.