On Sun May 4 23:21:00 2025 +0000, Brendan McGrath wrote:
This doesn't look right. Why would we pretend that sink requested
anything? I don't see why this would be necessary or different comparing to a regular start sequence. I agree, and my original fix made it the sinks responsibility to request a new sample. But in my testing on Windows, I couldn't see the sink ever make a request for a new sample after the flush. So my assumption was that the design on Windows was that it was the client's responsibility to request a new sample (i.e. if you call flush, you also provide the next sample). But maybe my test was wrong. I'll see if I can write one that I can include in this MR (and I'll then fix the implementation if necessary).
helpers names are not great
Agree actually. I used restart as they were called from the `SESSION_STATE_RESTARTING_SOURCES` path. But I shouldn't be naming functions based on where they are called from. I'll rename them to `session_flush_sinks` and `session_flush_transforms`.
I've just pushed a number of changes (which I've described in the MR description). But I found that the sink won't request a new sample if it has a request outstanding. Even after it is flushed and started in a new position. Under this circumstance, it is the clients responsibility to honor that outstanding request. But if no request is outstanding, then it does fall to the sink to make a new request. I've modified my MR to reflect those findings.