-
Notifications
You must be signed in to change notification settings - Fork 11
Quick fix at_lookup race condition #139
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
…that, because of the way in which the send and receive operate, it is quite possible indeed very likely that if two GETs, for example, are issued ~simultaneously, then the results will be mixed up
…that, because of the way in which the send and receive operate, it is quite possible indeed very likely that if two GETs, for example, are issued ~simultaneously, then the results will be mixed up
@murali-shris Please review at your earliest convenience; given the severity of this bug, I'd like to merge to trunk asap - ideally tomorrow I will add extra tests tomorrow morning (unit tests for at_lookup, as well as an end-to-end test) In the interim, @purnimavenkatasubbu it would be great if you could locally run all of the tests in
|
Issue documented at #140 |
Verified functional_tests of client_sdk locally and verified @mosphere_pro app pointing to the following in dependency_overrides Did not face any issues. Attaching POT's @mosphere_pro app recordings sending_notifications.mp4receiving_notifications.mp4auth.mp4 |
Thanks Purnima, great!
|
- What I did
AtLookupImpl._process()
to prevent race condition which surfaced during testing the mwc_demo end-to-end- How I did it
_process()
; modified_process()
to acquire the mutex to start with, and release it in afinally
block- How to verify it
at_client_sdk
with a dependency override for at_lookup to this branchat_lookup: 3.0.7
to at_client_sdk/at_functional_test/pubspec.yaml)- Description for the changelog
AtLookupImpl._process()
to prevent race condition