dropbox: backend SDK calls do not propagate caller cancellation #9688

Before you start

• I have searched the forum and the existing issues and this hasn't already been requested.
• I have checked the latest beta and this feature doesn't already exist.

Associated forum post URL

None. I searched the relevant forum discussions directly.

rclone version

rclone v1.75.0-beta.9999.17629d67b
- os/version: ubuntu 24.04 (64 bit)
- os/kernel: 6.8.0-107-generic (x86_64)
- os/type: linux
- os/arch: amd64
- go/version: go1.26.5
- go/linking: static
- go/tags: none

What problem are you trying to solve?

Summary

Dropbox backend operations receive a caller context.Context, but the backend stores the SDK's non-context client interfaces and calls their non-context methods. In the pinned SDK, those wrappers execute requests with context.Background(), so cancellation of the rclone caller context does not cancel an in-flight Dropbox request. This is source-proven; user-visible cancellation delay has not been reproduced.

Evidence

• backend/dropbox/dropbox.go:383-400 stores files.Client, sharing.Client, users.Client, and team.Client, rather than their context-aware interfaces.
• The backend calls non-context SDK methods throughout. For example, backend/dropbox/dropbox.go:2022-2024 calls UploadSessionStart, and backend/dropbox/dropbox.go:2055-2060 calls UploadSessionAppendV2, although uploadChunked has the caller context.
• rclone pins github.com/dropbox/dropbox-sdk-go-unofficial/v6 v6.4.0. In that SDK, UploadSessionAppendV2 delegates to UploadSessionAppendV2Context(context.Background(), ...) (source); the SDK also exposes context-aware client interfaces and methods.
• backend/dropbox/dropbox.go:448-475 checks the caller context during retry classification, which occurs only after the SDK call returns.
• Closed tracker #3257 established the context-propagation goal, listed Dropbox as unfinished, and closed with the maintainer noting that remaining work should happen in backend-specific issues.

Impact

The absence of caller cancellation from the in-flight HTTP request is source-proven. The resulting shutdown delay, stalled-request duration, and transfer impact have not been measured. Batcher finalization has a separate lifecycle and is not part of this report.

Question

Would it make sense for caller-scoped Dropbox operations to use the SDK's context-aware interfaces and *Context methods, while preserving independently owned batch-finalization contexts?

I checked all relevant issues, comments, pull requests, and forum threads; this report is not a duplicate.

How do you think rclone should be changed to solve that?

Store the SDK's context-aware client interfaces and call the corresponding *Context methods with each operation's caller context. Keep batcher-owned contexts where work intentionally outlives an individual call.

Getting involved

• I'm willing to help implement, test or fund this feature.

I am reporting this finding only and am not currently proposing a pull request.

Investigated extensively with GPT-5.6 Sol (xhigh reasoning effort), using Oh My Pi as the agent framework.