Stop delivering status updates when offline download is canceled

[danswick]

Platform: iOS and Android
Mapbox SDK version: latest of each

Steps to trigger behavior

1. Initiate an offline download
2. Cancel the download

Expected behavior

Download immediately stops and no further messages are sent.

Actual behavior

Messages continue to be sent.

Related issues: #5531, #4418, #4229

[1ec5]

Should the region (pack) go back to reporting its state as inactive? Is it safe for the developer to resume downloading the region at that point, before region would’ve stopped updating (with the current code)?

[zugaldia]

/sub

[dagatsoin]

Just to be sure is

public void cancelDownload(){
        _offlineRegion.setDownloadState(OfflineRegion.STATE_INACTIVE);
    }

the good way to cancel a download ?

[zugaldia]

Android has enabled an API to achieve this via #5696. Setting OfflineRegion.setDeliverInactiveMessages(true/false) will let you enable/disable the delivery of messages once a region has been set inactive.

[1ec5]

We’re leaving this ticket open to track a fix in mbgl that would obviate the API added in #5696.

[madsodgaard]

Any update on iOS ETA?

[1ec5]

There are no plans to add a dedicated API to work around this issue on iOS and macOS. Instead, this ticket is tracking a fix in core that would stop sending these notifications when appropriate. We consider it essentially a bug in core that the state is still reported as active and notifications keep coming in.

In the meantime, if you absolutely need the cancelation to appear to take effect immediately, the workaround on iOS and macOS is to keep track of the packs you've canceled or keep track of the fact that this particular pack has been canceled, and ignore progress notifications based on that.

/cc @jfirebaugh

[1ec5]

One consequence of this issue is that progress updates may be coming in after the developer has attempted to remove the offline pack. The errant progress updates would lead to bad memory access, as seen in #6092. The approach in #5696 wouldn’t address this race condition on iOS and macOS, because the MGLOfflinePack object has already been reclaimed by ARC by this point.

[jfirebaugh]

It's not possible to fix this at the core level. The status updates that to the main thread appear to come after the request to cancel a download were in fact sent by the asynchronous worker before it processed the request to cancel the download.

iOS and macOS should apply a fix similar to that applied on Android, where the main thread ignores notifications delivered after the request to cancel the download has been sent to the asynchronous worker.

[1ec5]

In that case, I don’t think it makes sense to add a dedicated “deliverInactiveMessages” property, as #5696 did, to the iOS/macOS SDK. The SDK should just do the right thing, which apparently means dropping these notifications.

[jfirebaugh]

#5508 is also related.