Calling debounce is causing async stream to get cancelled early

[zkline101]

I made a post about this here.

I was recently testing out the debounce method and I noticed some strange behavior that I didn't expect. It looks the async stream I have set up is getting cancelled early when I'm calling the debounce method but it doesn't do that without the debounce method. This seems like a bug but I'm curious to hear others thoughts on it.

Here is the reproducer I have. Thanks!

@Test
func debounceCancellation() async {
    enum Status {
        case inProgress
        case completed
    }

    let drawStatues = AsyncStream<Status> { continuation in
        Task {
            continuation.yield(.inProgress)
            try! await Task.sleep(for: .seconds(2))
            continuation.yield(.completed)
        }

        continuation.onTermination = { termination in
            switch termination {
            case .cancelled:
                print("Cancelled!")
            case .finished:
                print("Finished!")
            @unknown default:
                fatalError("Unknown case")
            }
        }
    }

    _ = await drawStatues
        .debounce(for: .seconds(2))
        .first(where: { @Sendable in $0 == .completed })

    // Current behavior when using debounce:
    // cancelled -> end
    //
    // Expected behavior without using debounce:
    // end -> cancelled

    print("End")
}

[da-hye0]

Hi — I dug into this a bit.

When .first(where:) finds its value, the iterator deinits, which calls iteratorDeinitialized() in
DebounceStorage. The state at that point is .waitingForDemand (after clockSleepFinished() delivers the
element and transitions from .debouncing).

The current implementation resumes the upstream continuation with CancellationError() and calls
task.cancel(). This propagates to the AsyncStream and triggers onTermination as .cancelled.

The root cause seems to be that iteratorDeinitialized() treats "consumer is done" the same as "consumer was
cancelled."

I considered resuming the upstream continuation normally (without throwing) to avoid the CancellationError
propagation, but task.cancel() would still propagate cancellation to the AsyncStream's next(). And even
without task.cancel(), when the upstream iterator is eventually dropped, AsyncStream appears to fire
onTermination with .cancelled regardless — which may be an AsyncStream-level behavior rather than something
fixable in debounce alone.

Would appreciate your thoughts on whether this is something that can be addressed at the debounce level, or if
it's fundamentally tied to how AsyncStream handles iterator deinitialization.