A throttled `AsyncSequence` doesn't yield its parent sequence's final value

[gregcotten]

Not sure if this is expected behavior.

I make an AsyncStream called stream, and a throttled sequence from that stream throttledStream. I yield values into stream for a while, and eventually call finish() on its continuation. All the while in the background I am iterating through throttledStream - when finish() gets called on stream, my iteration through throttledStream finishes, but I don't get the final value that was sent to stream.

Sorry this is kind of a complicated way to explain the issue, but I will make a reproducible example project if this behavior sounds like it is indeed not intended!

[gregcotten]

I should add, I guess it's the "penultimate" value I'm looking for - I realize that nil is the final value in a "finished" AsyncStream

[twittemb]

Is it a throttle with “latest” ? If not then it can be normal that the penultimate element is skipped.

[gregcotten]

Is it a throttle with “latest” ? If not then it can be normal that the penultimate element is skipped.

Yes, latest = true, just calling let throttledStream = stream.throttle(for: .seconds(1), latest: true), for example.

[twittemb]

@gregcotten

Keep in mind that AsyncSequence is a pull mechanism whereas Combine is a push mechanism for instance. It means that the throttling is applied to the pace of the consumer, not the producer.

in your case, let’s say you have a throttling duration of 1s, here is what I suspect is happening at the end of the timeline:

|
| x -> last received element by the consumer, a new throttling start time is set, ending in 1s
| y -> new element is discarded because it is too close to ‘x’ (the time elapsed since the start is < 1s)
|
| z -> last element is discarded because it is too close to ‘x’ (the time elapsed since the start is < 1s)
|
| nil -> the upstream sequence is finished before the theoretical end of this throttling session
|
| ——> theoretical end for the current throttling session (start + 1s)
V

In the end the consumer doesn’t receive the penultimate element but the last that matches a throttling session’s end, that is to say ‘x’.

I hope this helps. @FranzBusch could also chime in to confirm or not (he made the algorithm I think).

[gregcotten]

Yes, this behavior makes sense to me, but I think it might be nice to find a way to always get the penultimate value somehow... Would a PR be welcome for this?

[twittemb]

Yeah I can see how that would be useful. Let’s say you throttle a text field (like a search field), with the current implementation you would not have the last character … which would be wrong search wise.

@FranzBusch what’s your take on that ? Should we switch to another implementation that:

• iterate over the upstream sequence in a dedicated Task and push the values into a “Throttle” state machine
• run a “tick” periodically in a dedicated task and push each “tick” into the “Throttle” state machine
• for every “tick” use the “Throttle” state machine to retrieve the appropriate value and push it into a kind of “unicast buffered state machine”
• expose the “unicast buffered state machine” to the consumers

It would be much closer to what throttling does in push based system … but with the drawback of not be based on the consumer pace.

[FranzBusch]

Couldn't we just change the implementation of throttle to check if there is a latest value when the upstream returns nil and then return the latest value. IMO we could also make this the default but would like to get @phausler on this as well.

[gregcotten]

Couldn't we just change the implementation of throttle to check if there is a latest value when the upstream returns nil and then return the latest value. IMO we could also make this the default but would like to get @phausler on this as well.

That makes sense to me. Would the final value still be throttled or debounced at the specified interval, or would we break the contract for the "final" value?

[FranzBusch]

That makes sense to me. Would the final value still be throttled or debounced at the specified interval, or would we break the contract for the "final" value?

Good question. I would like to understand what the current standard in other frameworks is. If we could get a little comparison going here that would be nice to make an informed choice.

[gregcotten]

@FranzBusch My initial thought would be to respect the specified throttle interval when deciding when to emit the final value.

[phausler]

Combine for example used the rule for throttle and debounce: that the iterative output (not the signals to determine failure or finishedness) are the rate limited things. So specifically for throttle; it means that even the last value should not emit any faster than the requested throttling rate.

The intent for folks using throttle is that they don't ever want a rate beyond a given value. Making the last value ignore that would break folks expectations.

[twittemb]

It might be difficult to achieve with the current implementation since we have no way to determine that a value is the final value. We cannot postpone the emitting until the throttling duration is finished.

That's why I suggested to rely on a tick mechanism but it makes things significantly more complex and changes the way the upstream sequence is being iterated over.

[FranzBusch]

Thanks for clarifying the behaviour @phausler. I think that makes sense but it also means we will be dropping the final values in some cases which IMO is correct. If you throttle you have to live with the fact that you might be losing values which you are already due to the rate limiting.