User is available, push is sent, user updates location, assignments are cleared, user is not longer available

[youralien]

Kapil:

Critical incident! I’m currently commuting up on lakeshore drive and got a Notification to participate in half half travel. But my location updated before I could participate, so when I go into the app all I see is a blank screen

Leesha

She opened the new experience (it was a blank white screen), she opened and reclosed the app. Opening it again, she got the experience but then was immediately taken off.

Logs

018-07-25T15:57:19.087277+00:00 app[web.1]: �[32m[info]: user drgd3XW5Dmp6DLw7M | userAvailability: {"rDuzhNBNmKLWEHJZn":["Hand Silhouette"]} | can participate? true�[39m

2018-07-25T15:57:19.161428+00:00 app[web.1]: �[36m[cerebro]: Sending push notifications to drgd3XW5Dmp6DLw7M�[39m

2018-07-25T15:57:19.161488+00:00 app[web.1]: �[36m[cerebro]: {"title":"Event Body Mirror is starting!","text":"Your situation made you available to participate in Body Mirror!","iid":"rDuzhNBNmKLWEHJZn","route":"apiCustom/rDuzhNBNmKLWEHJZn/Hand Silhouette"}�[39m

2018-07-25T15:57:20.189824+00:00 app[web.1]: �[32m[info]: POST to api/geolocation: {"location":{"coords":{"speed":-1,"longitude":-87.64014906963257,"floor":null,"latitude":41.939711757587574,"accuracy":65,"altitude_accuracy":10,"altitude":183,"heading":-1},"extras":{},"is_moving":true,"odometer":216990.3,"uuid":"5B0233E5-CD88-46F6-B8F6-9B1EF2A187E5","activity":{"type":"on_foot","confidence":66},"battery":{"level":0.9200000166893005,"is_charging":false},"timestamp":"2018-07-25T15:57:19.856Z"},"userId":"drgd3XW5Dmp6DLw7M"}�[39m

2018-07-25T15:57:20.191282+00:00 app[web.1]: �[32m[info]: Location update for drgd3XW5Dmp6DLw7M: removing them from all availabilities and getting new affordances.�[39m

2018-07-25T15:57:20.242337+00:00 heroku[router]: at=info method=POST path="/api/geolocation" host=ce-platform.herokuapp.com request_id=956d3ccc-c47e-43af-ad02-95e177ef8a80 fwd="174.221.16.201" dyno=web.1 connect=1ms service=57ms status=200 bytes=1205 protocol=https

2018-07-25T15:57:20.698249+00:00 app[web.1]: �[32m[info]: Affordances successfully retrieved for drgd3XW5Dmp6DLw7M at 41.939711757587574, -87.64014906963257.�[39m

2018-07-25T15:57:20.709531+00:00 app[web.1]: �[32m[info]: triggering internal location update for: drgd3XW5Dmp6DLw7M�[39m

2018-07-25T15:57:20.722052+00:00 app[web.1]: �[32m[info]: user drgd3XW5Dmp6DLw7M cannot participate yet.�[39m

Solutions

• Might need finer grained logic for when someone should not be available. For example, if someone is notified, but didn't participate, they should unavailble for a small amount of time (like 2 minutes) vs if you did successfully participate, the amount should be longer (like 1 hour)

[kapil1garg]

One fix to try is as follows:

• For every function that resets availability or assignments in the onLocationUpdate function, first check to see if the new affordances are the same as before. One way to check this is to see if users can still match the needs given their new location and affordances. If so, then we shouldn't pull their availability since it's still valid
• Any places where we try to use location data as a decision variable (ex. in timeouts when starting the coordinator, we look to see if new location is <= 10.0 meters away), check if the affordances match instead since CE is really only thinking about affordances and not actual location. This should allow for cases where a user might be walking through a park to be notified anytime they are in the park since their affordances still match the park (whereas now, they wouldn't be able to participate unless they were in the park AND relatively stationary due to the 10m threshold in timeouts).

See below for some of the sketches we made regarding this issue.
Whiteboard.pdf

I'll work on implementing the above while @youralien works on generating simulations of potential scenarios that users may go though (ex. walking to a place, stopping and getting matched with need, walking again; walking through a large place like a park where affordance is always valid) so we can test the changes against that.

[youralien]

I don't have the perfect test cases yet, but I wrote a script that pulls from the location_log history and replays location update events, in the timed sequence that they happened. I've been slowly adding several events of interest/failure in this file

https://github.com/jenniewerner/CEextras/blob/location-tracking/play_from_location_log.py

[youralien]

TL;DR: Tried to change the interface model so that notifications for OCEs would be cleared or retracted. However, the package call for clearAllNotifications does nothing. Attempted changes at this commit in case anyone wants to pick up where I left off. To test, I went to a web client, and send a silent push notification with empty text and a null route Meteor.call('sendNotification', ["hTkMMjv39hwdq2sM5"], "", null).

1. Other possible change to the interface model is to send another notification, apologizing that they missed the opportunity. Right now, the home screen has an apology, but no one is seeing that.

2. Instead of limiting availability to participate based on when you were last notified, do it on last participated. I see in identifier.js that we used to have a waitTimeAfterNotification and a waitTimeAfterParticipating, which were different.

[youralien]

I am going to keep this open. However, #78 worked on parts of this issue. Namely,

• User Interface Fix: Sends users a notification if they missed a chance to participate
• System Fix: User will get notified for new experiences, if they missed a change to participate. They won't be limited by the last time they got a notification.