Implement stopProvidingItem cancellation

Open
  • Is something wrong?
#472 0 comments 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
45/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Quiet
Tech stack
ios, swift
Domain
mobile-dev

Research direction

Start at FileProviderAdapter.stopProvidingItem(at:) and trace how in-flight URLSessionTask, Workflow, WorkflowScheduler permits, and DownloadTaskRecord are tracked. Compare the WebDAV onTaskCreation path with SDK-backed providers, including cancellation when no prior startProvidingItem exists. Done means cancellation is safe, cleanup and permit release occur, and completion is signaled.

Written by the indexing model from the issue text.

Description

state:confirmed

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.

Dominant language
Swift
Stars
295
Forks
42
Avg merge
1h 43m
Merged PRs (30d)
1

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from cryptomator/ios

All issues in cryptomator/ios

Similar issues

More Swift issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.