Does Combine's timeout operator cancel the upstream publisher after firing?

Answer

Combine's .timeout(_:scheduler:) emits a failure downstream when the specified interval elapses, but it does not cancel the upstream publisher.

Confirmed Facts

• The operator does not send a cancel event upstream upon firing.
• An underlying URLSessionDataTask continues running after the timeout error is delivered unless the subscription is explicitly cancelled.
• Holding the AnyCancellable while a timeout fires does not stop upstream work; only releasing or calling .cancel() on the cancellable triggers upstream teardown.
• The scheduler argument determines where the timer is measured and delivered, but it does not alter these cancellation semantics.

Verification Steps

1. Insert .handleEvents(receiveCancel: { print("Cancelled") }) immediately before the .timeout operator. If the log does not appear when the timeout fires, the upstream remains active.
2. Monitor the URLSessionTask.state after the timeout error is received. A state of .running confirms the task survived the timeout.
3. Use the Instruments Network template to observe if data transfer continues after the downstream failure is triggered.

Tying Cancellation to Timeout

To ensure resources are freed, you must explicitly cancel the subscription when the timeout failure arrives. This can be achieved by calling cancel() on the stored AnyCancellable within the sink completion handler or using handleEvents.

var cancellable: AnyCancellable?
cancellable = URLSession.shared.dataTaskPublisher(for: request)
    .timeout(5, scheduler: DispatchQueue.main)
    .handleEvents(receiveCompletion: { completion in
        if case .failure = completion { cancellable?.cancel() }
    })
    .sink(receiveCompletion: { _ in }, receiveValue: { _ in })

Behavior Across Publisher Types

• DataTaskPublisher: The task runs independently of the timeout; explicit cancellation is required to stop the network request.
• Future: Since Future is eager, the work starts upon creation. A timeout may signal failure downstream, but it cannot stop the internal work unless the Future was specifically designed with a cancellation hook.
• Just with delay: The delayed value is cancelled if the subscription is torn down, but the timeout operator itself does not trigger that teardown.

Missing Diagnostic Detail

Are you retaining the AnyCancellable in a collection (like a Set<AnyCancellable>) or a single variable? If the cancellable is discarded immediately upon the timeout error, the upstream will be cancelled by the deinit of the cancellable rather than by the operator itself.