Delayed reports from CMFallDetectionManager

Thanks for another detailed issue report—we appreciate it, and for better or worse, you have an amazing hit rate so far. :-) Do you have a FB number that we can use for the investigation? We can of course paste this into one we create internally, but one you file would be helpful if we need to follow up.

Thank YOU for being responsive to all of this! The team can feel free to send us either flowers or a lump of coal, depending on how they feel about getting these :)

FB13788575 submitted.

I should add that the user was located in Central time which is -5 hours from UTC. Since the observed delay was 5 hours and 4 minutes, I wonder if there is an issue with time zones and message delivery to our app. If you remove the 5 hours component we end up with a 4-minute delay which is still not ideal but in line with what we've seen on those other events. Also, the watch was running watchOS 10.2.

To be clear, though, the vast majority of our users are located in the continental U.S. and we haven’t seen similar multi-hour delays from their devices.

I have updated the feedback with this information as well.

Thank you!

I got followup from the submitted feedback, which I'm posting here:

"Please know that our engineering team has determined that this issue behaves as intended based on the information provided.

The API won't get notified until the first party flow and SOS resolution is complete. For example if an emergency call is placed, the API wont get notified until the call ends and emergency contacts have been notified (if setup). This could explain the 3-5 minute delay observed by the developer between the time of the fall and the API getting notified."

While the feedback response explains the 3-5 minute delay, it does not explain the 5 hour delay we witnessed. I answered the feedback to emphasize that the core issue remains unaddressed, but the FB is already marked as "closed" so I don't expect any further action. Is there any way to get further guidance here?

In case it wasn’t clear from the response, your point above about the time zone is correct, so all that was left was to explain the 4 minute delay, which the team did. If you think there still might be an issue here, reaching out to DTS is probably the next step, so you can review your code together. There might be a misunderstanding in the implementation, or with further inspection it might be clearer how to point out a flaw that we should address. At the moment, all signs point to the feature working as expected.

I must have expressed myself poorly then. My observation about the time zone was meant to raise a hypothesis for why the system delayed the alert for 5 hours and 4 minutes. But, it's clear that the alert was delayed.

– The user reported an approximately 5 hour delay in the alert delivery from the observed event.

– Our logs also reported the 5 hour delay. Recall that our logging output code is "Fall detected at (event.date) with status (event.resolution.rawValue) at (Date())". The resulting output prints the dates in UTC time, as shown in the fragments in my original post. The gap between the event.date value and the value returned by the Date() function (both printed in UTC) in this instance was 5 hours and 4 minutes.

So to be crystal clear and to reiterate, we did see a 5 hour 4 minute delay for a user, and while the 4 minute component seems to be accounted for by this explanation, the 5 hour component remains a mystery.

I see it on the radar. Please continue to follow up there. No need to post in both places.

Understood! I didn't know how much overlap there was between the two areas. I'll focus on the feedback for now, and will only update here with any final answers that could be helpful for posterity.