-
Notifications
You must be signed in to change notification settings - Fork 12
[PM-20615] Only process incoming messages once #264
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
Conversation
Sorry for assigning this to you too @dani-garcia, but I don't think anyone else has experience with Send + Sync |
Great job, no security vulnerabilities found in this Pull Request |
I'm debugging the tests now but apparently they only fail when you run Edit: Fixed |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #264 +/- ##
==========================================
- Coverage 70.32% 70.29% -0.03%
==========================================
Files 217 216 -1
Lines 16992 17060 +68
==========================================
+ Hits 11949 11992 +43
- Misses 5043 5068 +25 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
(cherry picked from commit 875c3a9)
(cherry picked from commit 875c3a9)
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.
Some comments about the locking we're doing, but otherwise LGTM
@@ -1,3 +1,8 @@ | |||
#[cfg(all(target_arch = "wasm32", not(feature = "wasm")))] | |||
compile_error!( | |||
"The `wasm` feature must be enabled to use the `bitwarden-ipc` crate in a WebAssembly environment." |
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.
bitwarden-threading doesn't have any feature defined in cargo.toml, does it? Why is this needed?
I wonder if we should decide whether we want to use target_arch = "wasm32" or feature = "wasm" and just update the whole repo to be consistent.
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.
I added a wasm
feature. I needed to add it because the crates that depend on threading
use features and so I had to either convert them to target_arch
too or convert threading
to use feature
.
Yeah, I think features has some advantage but I can't remember what 🙃 So far adding the wasm
flag to a non-wasm build (which we do when we run cargo test --all-features
) hasn't caused any issues because wasm-bindgen
has a goal to always compile on all target and instead throw runtime errors if you try to use it on an unsupported target. But now, we have this thing:
#[cfg(not(target_arch = "wasm32"))]
use tokio::task::spawn_local;
#[cfg(all(target_arch = "wasm32", feature = "wasm"))]
use wasm_bindgen_futures::spawn_local;
which is actively used in unit-tests and so all of a sudden we cannot just do
#[cfg(not(featgure = "wasm"))]
use tokio::task::spawn_local;
#[cfg(feature = "wasm")]
use wasm_bindgen_futures::spawn_local;
because that would cause wasm_bindgen_futures::spawn_local
to be called during a regular unit test which would cause a runtime error.
So either we remove wasm
from cargo test
(cargo test --all-features --except wasm
???) or we use target_arch
|
🎟️ Tracking
📔 Objective
BitwardenClient
⏰ Reminders before review
team
🦮 Reviewer guidelines
:+1:
) or similar for great changes:memo:
) or ℹ️ (:information_source:
) for notes or general info:question:
) for questions:thinking:
) or 💭 (:thought_balloon:
) for more open inquiry that's not quite a confirmedissue and could potentially benefit from discussion
:art:
) for suggestions / improvements:x:
) or:warning:
) for more significant problems or concerns needing attention:seedling:
) or ♻️ (:recycle:
) for future improvements or indications of technical debt:pick:
) for minor or nitpick changes