FileProviderAdapter.stopProvidingItem(at:) is a #warning("TODO") no-op. iOS calls it when the last claim on a file is released, which includes re-tapping a file that is still downloading in Files.app. Because we ignore it, the in-flight URLSessionTask keeps running, its WorkflowScheduler download permit is never released, and no completion is signaled back. fileproviderd and the extension then disagree about the item's state until the extension is respawned, and the user sees "Couldn't communicate with a helper application."
Confirmed on device (iOS 26.5): stopProvidingItem logged, followed by roughly six minutes of silence from the extension, then a respawn. With maxParallelDownloads: 2, two of these are enough to stall every later download in the vault until the vault is locked and unlocked.
This is separate from #449 and predates it. #467 fixed the resume-before-register ordering and deliberately left this out of scope.
A fix needs to map the item identifier to the in-flight URLSessionTask, cancel it, tear down the Workflow and release the scheduler permit, remove the DownloadTaskRecord, and signal completion. Two things to be careful about: stopProvidingItem does not imply a prior startProvidingItem for the same URL, since fileproviderd can release a queued claim before content is ever materialized, so cancellation has to tolerate having nothing to cancel. And onTaskCreation is only invoked by the WebDAV provider in cloud-access-swift, so a task handle exists for WebDAV but not for the SDK-backed providers, which need a different cancellation path or none at all.
FileProviderAdapter.stopProvidingItem(at:)is a#warning("TODO")no-op. iOS calls it when the last claim on a file is released, which includes re-tapping a file that is still downloading in Files.app. Because we ignore it, the in-flightURLSessionTaskkeeps running, itsWorkflowSchedulerdownload permit is never released, and no completion is signaled back. fileproviderd and the extension then disagree about the item's state until the extension is respawned, and the user sees "Couldn't communicate with a helper application."Confirmed on device (iOS 26.5):
stopProvidingItemlogged, followed by roughly six minutes of silence from the extension, then a respawn. WithmaxParallelDownloads: 2, two of these are enough to stall every later download in the vault until the vault is locked and unlocked.This is separate from #449 and predates it. #467 fixed the resume-before-register ordering and deliberately left this out of scope.
A fix needs to map the item identifier to the in-flight
URLSessionTask, cancel it, tear down theWorkflowand release the scheduler permit, remove theDownloadTaskRecord, and signal completion. Two things to be careful about:stopProvidingItemdoes not imply a priorstartProvidingItemfor the same URL, since fileproviderd can release a queued claim before content is ever materialized, so cancellation has to tolerate having nothing to cancel. AndonTaskCreationis only invoked by the WebDAV provider in cloud-access-swift, so a task handle exists for WebDAV but not for the SDK-backed providers, which need a different cancellation path or none at all.