Lack of handling for CancellationSignal in Document Provider means clients are forced to wait
- Dominant language
- Kotlin
- Stars
- 5.6k
- Forks
- 2k
- Avg merge
- 2d 18h
- Merged PRs (30d)
- 92
Description
### Is your feature request related to a problem? Please describe.
Document providers are normally supplied a CancellationSignal object as an argument to document provider functions. The intent is for the object's ``set'' state to be periodically examined during any prolonged network or IO requests constituting part of the document provider operation, and to cancel them should the signal ever be set.
Nextcloud neglects to examine cancellation signals furnished in any manner, which inhibits apps (like the Android port of Emacs) from ever quitting until the operations are complete.
### Describe the solution you'd like
Nextcloud should be corrected to examine cancellation signals, as illustrated above.
### Additional context
This issue has been raised by an Emacs developer working on an Android port, with support for SAF document providers.
Such lack of examination for cancellation signals inhibits Emacs from ever quitting until the operations are complete.
Contributor guide
Assessment
This issue has not been assessed yet.