-
Notifications
You must be signed in to change notification settings - Fork 32
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
[bug] Failure in recreating the geofence after reboot causes the app to be stuck in waiting_for_trip_start
forever
#678
Comments
Starting with Malawi...; the user reports that they only had the outgoing trip recorded on 4th Sept; the return trip was missing. Here's what we see for that user: Trip started at 8:22
Trip ended at 8:32 and new geofence was created
Then we tried to create a geofence again 10 mins later. At this point, the current location was null. We tried to read the location so we could create the geofence...
We never did get said location, so we skipped creating the geofence. |
So what happened between 8:32, when we successfully created the geofence and 9:44 when we tried to create it again, and failed? Here's where we successfully created the geofence; we are now waiting for the trip start.
The app was launched a few minutes later and the user accessed the label and
Then, an hour later, we had a periodic call
Then, we had another of those quick reboots
but we weren't able to access the location, so we weren't able to create a geofence. All settings were valid, so this is probably due to poor GPS sightlines, or being too close to startup or ???
The next periodic call was in around an hour. And we were in the
Whoa! That seems like a real bug. It looks like we don't reset to the start state if we are in This continues for the rest of the day.
|
Bingo The second issue also seems to be the same.
There's some additional complexity in this one, but I think it comes down to the same error. |
Additional complexity: We started off with tracking stopped, then the app was launched, and tracking was turned on.
However, there were persistent issues with location availability so we were not able to create the geofence.
However, right after that we got a bunch of locations - I guess the location
After that, we stay in that state, quite correctly, until 1pm on the next day.
Then, we rebooted!! Really and truly.
In the subsequent sync, we again didn't get any location points, probably
|
waiting_for_trip_start
forever
Another report: missing all trips between 14th and 17th. Everything is fine until the 2021-09-14T17:....
Then we start a sync
which generates an initialize (unsure why, no reboot?)
Again, we can't create the geofence, and so all tracking is off until the next reboot re-initializes the FSM.
|
This is because the foreground service was killed just before that, and we reinitialize the FSM in that case. We see this happening consistently for this user. Most of the time, the initialize succeeds; it failed in this one case.
|
Focusing only on the BootReceiver and the killed notification, they seem to be fairly correlated, but not perfect.
Not sure why we should get a |
Focusing on a couple of instances of this...
First sync, killed notification detection
Second sync almost immediately afterwards!!
And then the reboot:
|
Similarly,
|
Looks like most of the reboots were super fast (under 1 minute).
|
I see this pattern of very short restarts for the Malawi user as well.
More and more
|
More reboots for the same user.
More, more, more
|
The trip segmentation algorithms do handle reboots, of course, but they assume that they are rare, and that we don’t know what the start point of the post-reboot trip is, so they don’t fill in the start of the trip. If they are this common and this short, I might need to handle them differently. |
This appears to be similar to #677 but happens much more infrequently.
On the order of one missing day over multiple months.
Reported by participants from Malawi and Denver.
Not sure if the underlying issue is the same for both of them.
The Malawi user, at least, had a pre-android 8.0 phone, so the foreground service is not necessary.
The Denver user has android 11, which should have the most restrictions ever.
The text was updated successfully, but these errors were encountered: