Skip to content
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

NAVAND-1472: do not always relaunch timer when routes are updated #7497

Merged
merged 4 commits into from
Sep 21, 2023

Conversation

dzinad
Copy link
Contributor

@dzinad dzinad commented Sep 3, 2023

No description provided.

@dzinad dzinad requested a review from a team as a code owner September 3, 2023 19:46
@github-actions
Copy link

github-actions bot commented Sep 3, 2023

Changelog

Features

Bug fixes and improvements

  • Improved navigation positioning in tunnels. [#7514](https://github.com/mapbox/mapbox-navigation-android/pull/7514)
  • Fixed an issue where route refresh interval might have been too long in case of a specific alternatives update rate. [#dd](https://github.com/mapbox/mapbox-navigation-android/pull/dd)

Known issues ⚠️

Other changes

Android Auto Changelog

Features

Bug fixes and improvements

  • The app is now considered as the one in active navigation only when an active route is set to MapboxNavigation. Previously it was always considered active. [#7366](https://github.com/mapbox/mapbox-navigation-android/pull/7366)
  • When Android Auto host tells the app to stop active navigation because another app starts navigating, now SDK will enter FreeDrive mode instead of stopping trip session completely. [#7366](https://github.com/mapbox/mapbox-navigation-android/pull/7366)

@codecov
Copy link

codecov bot commented Sep 3, 2023

Codecov Report

Merging #7497 (40aef2a) into main (285009e) will increase coverage by 0.03%.
The diff coverage is 98.73%.

Impacted file tree graph

@@             Coverage Diff              @@
##               main    #7497      +/-   ##
============================================
+ Coverage     74.13%   74.16%   +0.03%     
- Complexity     6141     6151      +10     
============================================
  Files           829      830       +1     
  Lines         32883    32927      +44     
  Branches       3916     3925       +9     
============================================
+ Hits          24377    24420      +43     
- Misses         6973     6974       +1     
  Partials       1533     1533              
Files Changed Coverage Δ
...n/java/com/mapbox/navigation/core/utils/Delayer.kt 92.85% <92.85%> (ø)
...ava/com/mapbox/navigation/core/MapboxNavigation.kt 71.19% <100.00%> (ø)
...re/routerefresh/ImmediateRouteRefreshController.kt 100.00% <100.00%> (ø)
...core/routerefresh/PlannedRouteRefreshController.kt 100.00% <100.00%> (ø)
...gation/core/routerefresh/RouteRefreshController.kt 100.00% <100.00%> (ø)
...ore/routerefresh/RouteRefreshControllerProvider.kt 100.00% <100.00%> (ø)
...gation/core/routerefresh/RouteRefresherExecutor.kt 100.00% <100.00%> (ø)

@VysotskiVadim
Copy link
Contributor

I'm wondering, how stable the tests are. I see many assumptions that 1-1.5 second accuracy i enough, did you check if that works?

@@ -62,7 +62,7 @@ class RouteRefreshController internal constructor(
}
plannedRouteRefreshController.pause()
immediateRouteRefreshController.requestRoutesRefresh(routes) {
if (it.value?.anySuccess() == false) {
if (it.isValue) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why don't we resume in case of failture?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Null here doesn't mean failure. Null means it wasn't executed because a newer request came along.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

does null mean that another request was scheduled and current is cancelled so that we don't need to resume planned refreshes?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, because we'll think of that when the new request finishes, this on is just replaced by a new one.
It's not super clear, I think it'd be better to introduce some descriptive enum instead of Expected.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it'd be better to introduce some descriptive enum instead of Expected.

Great idea 👍

}

@Test
fun route_refresh_on_demand_after_reroute() = sdkTest {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

have you considered verifying behaviour in a unit test which tests RouteRefreshController which uses real implementation or Immediate and planned route request so that only router is mocked? I think those types of situations could be emulated there.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes. We have such unit tests. But the point here is that routes change externally (from MapboxNavigation). There is also filtering by reason there. That's why I want to check everything together here.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is also filtering by reason there.

Why not to move filtering by reason to route refresh controller?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I updated the tests.

@dzinad
Copy link
Contributor Author

dzinad commented Sep 4, 2023

I'm wondering, how stable the tests are. I see many assumptions that 1-1.5 second accuracy i enough, did you check if that works?

Looks like they are fine.

val refreshedRoutes = listOf(it.primaryRouteRefresherResult.route) +
it.alternativesRouteRefresherResults.map { it.route }
routesToRefresh = refreshedRoutes
scheduleNewUpdate(refreshedRoutes, false)
Copy link
Contributor

@VysotskiVadim VysotskiVadim Sep 5, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I really like that route refresh controller doesn't wait for new routes set from directions session to start the next cycle of refresh, we probably should have done it from the beginning. That decreases coupling + this dependency has never been obvious to me.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

++, it took me a while to understand how that works.

@@ -111,6 +111,7 @@ class RouteRefreshController internal constructor(

internal fun requestPlannedRouteRefresh(routes: List<NavigationRoute>) {
routeRefresherResultProcessor.reset()
immediateRouteRefreshController.cancel()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is that supposed to be called only for new routes?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think so. Otherwise we might get updated routes that are now changed.
When immediate refresh finishes, the routes might have already been changed. We'd get a race here. We'll notify RoutesObserver with old refreshed routes.


val routeOptions = generateRouteOptions(twoCoordinates)

mockWebServerRule.requestHandlers.remove(failByRequestRouteRefreshResponse)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why do you remove failByRequestRouteRefreshResponse? 🤔

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I want to replace refresh handler. For that I need to remove the old one.

Comment on lines 953 to 958
listOf(
RouteRefreshExtra.REFRESH_STATE_STARTED,
RouteRefreshExtra.REFRESH_STATE_CANCELED,
RouteRefreshExtra.REFRESH_STATE_STARTED,
RouteRefreshExtra.REFRESH_STATE_FINISHED_SUCCESS,
),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

given the first delay of 5 seconds and the second of 2 seconds and refresh interval 3 seconds, so that 2 route refresh happen, shouldn't states contain two REFRESH_STATE_FINISHED_SUCCESS?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This one actually is duplicated by a unit test so it has to be deleted.
Wrt your question, the first attempt will fail, so no, only one success.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, I didn't notice NthAttemptHandler

@dzinad dzinad force-pushed the NAVAND-1472-dd branch 4 times, most recently from d5f0d37 to acf4a34 Compare September 19, 2023 16:42
@dzinad dzinad enabled auto-merge (squash) September 20, 2023 14:06
@dzinad dzinad disabled auto-merge September 20, 2023 15:38
@dzinad dzinad enabled auto-merge (squash) September 20, 2023 15:44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants