Do not pass schedule munging failure to iOS app - just log it #246
Conversation
This failure doesn’t really tell the partipants anything useful so showing them an alert is less useful then logging it to crashlytics.
| if (!adherenceRecordRepo.loadRemoteAdherenceRecords(studyId)) { | ||
| updateFailed?.invoke() | ||
| } | ||
| !adherenceRecordRepo.loadRemoteAdherenceRecords(studyId) |
There was a problem hiding this comment.
If this throws an error, then it is already being logged.
| repo.getStudyBurstSchedule(studyId).collect { timelineResource -> | ||
| (timelineResource as? ResourceResult.Success)?.data?.let { schedule -> | ||
| viewUpdated(schedule.toNative()) | ||
| } ?: run { | ||
| if (timelineResource is ResourceResult.Failed) { | ||
| updateFailed?.invoke() | ||
| Logger.e("Update of the `StudyBurstSchedule` failed.", | ||
| Throwable("Reason Unknown.")) |
There was a problem hiding this comment.
The previous behavior was to pop an alert to the participant that said: "Error: An error has occurred" which was not particularly helpful. I'm not seeing anywhere that the failure is being logged so just using a general purpose try/catch here.
| private val viewUpdate: (NativeScheduledSessionTimelineSlice) -> Unit | ||
| ) : AbstractNativeTimelineManager(studyId, scheduleMutator) { | ||
| ) : AbstractNativeTimelineManager(studyId, null) { |
There was a problem hiding this comment.
This is the TimelineManager used by Open Bridge App, which does not use the schedule mutator. Since I'm proposing that we move the logic for mutating the schedule per participant into BridgeClientKMM, I don't think we want to support the external mutator.
|
Nvmd. Closing - it's going to take more effort to unravel why this is being passed to the app. |
This failure doesn’t really tell the partipants anything useful so showing them an alert is less useful then logging it to crashlytics.