-
Notifications
You must be signed in to change notification settings - Fork 319
block until deprecated MapboxNavigation#resetTripSession() finishes #6705
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
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -143,6 +143,7 @@ import kotlinx.coroutines.cancel | |
| import kotlinx.coroutines.channels.Channel | ||
| import kotlinx.coroutines.channels.ReceiveChannel | ||
| import kotlinx.coroutines.launch | ||
| import kotlinx.coroutines.runBlocking | ||
| import kotlinx.coroutines.sync.Mutex | ||
| import kotlinx.coroutines.sync.withLock | ||
| import java.lang.reflect.Field | ||
|
|
@@ -645,10 +646,18 @@ class MapboxNavigation @VisibleForTesting internal constructor( | |
| * navigation simulation, or before resetting location to not real (simulated) | ||
| * position without recreation of [MapboxNavigation]. | ||
| */ | ||
| @Deprecated(message = "use a function withe the callback instead") | ||
| @Deprecated(message = "use the overload with the callback instead") | ||
| fun resetTripSession() { | ||
| resetTripSession { | ||
| // no-op | ||
| // using a blocking function to keep parity with the original implementation so that | ||
| // Nav Native is fully done with the reset when this function returns | ||
| runBlocking { | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @LukasPaczos , from the first glance it seems like it should always cause a deadlock:
I was surprised that it works and it turned out that NN calls the callback from their worker thread without rescheduling to the main thread, which is not typical for NN's API. Do you think it's safe to rely on this implementation detail of NN? I worry that if they change it, deprecated version of
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Thanks for raising this. In the end no, we shouldn't really rely on this. This is a strong enough reason to try and find a different approach or work with Nav Native to leave the old function be, even if deprecated. Tracking in NAVAND-984.
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Adding a test as a safeguard that would block us from adopting a NN version that would break this logic - #6710. |
||
| logD(LOG_CATEGORY) { | ||
| "Resetting trip session" | ||
| } | ||
| navigator.resetRideSession() | ||
| logI(LOG_CATEGORY) { | ||
| "Trip session reset" | ||
| } | ||
| } | ||
| } | ||
|
|
||
|
|
||
Uh oh!
There was an error while loading. Please reload this page.