-
-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
Element-R: hang during login #25779
Comments
This is back |
There is a test that is supposed to catch this ( |
I now can't reproduce this. |
We're still seeing this intermittently |
The root cause here is failures to clean up objects on the rust side during logout, which means we end up holding onto a connection to the IndexedDB. That means that we can't delete the IndexedDB, and when we log in again, attempts to open the IndexedDB block indefinitely. The reason that the Rust objects aren't being cleaned up is that we're relying on javascript's We could attempt to explicitly call A more plausible solution is to update the matrix-rust-sdk |
@gmanskibiditoilet what does this issue have to do with me? If you continue to randomly tag me I'll just block you so I don't get notifications unrelated to anything I'm involved with while I'm on holiday. |
ok sorry |
This reverts commit eea167e. Unfortunately, most of this change is unsound. With an explicit `future_to_promise`, we are able to clone the underlying `matrix_sdk_crypto::OlmMachine` (and its constituent `Arc`) *before* returning a Promise to the javascript, meaning even if the wrapping `matrix_sdk_crypto_wasm::OlmMachine` is dropped, the underlying `OlmMachine` hangs around. An `async` function does nothing until it is polled, meaning there is plenty of time for the Javascript to get hold of the Promise and drop its reference to the OlmMachine, before we try and clone it. I think it's fine if we let the Javascript finalizer manage cleanup; but we deliberately drop OlmMachine, in an attempt to get it to drop its indexeddb conneciton. I'd go so far as to say that wasm-bindgen's support for `#[wasm_bindgen]` on `async fn` (rustwasm/wasm-bindgen#1754) is fundamentally incompatible with an explicit call to `.free()` (or, in this case, `.close()`, which is the same thing.) Probably, the correct fix here is to improve the way we handle indexeddb connections (cf element-hq/element-web#25779), at which point we can remove the `.close()`/`.free()` calls, and reintroduce this. For now though, I'm going to back it out.
Sometimes:
I think it's something indexedDB related. From the logs:
note
cannot yet remove IndexedDB instance
in particular.It's fine after a reload.
The text was updated successfully, but these errors were encountered: