Order of streams in SessionWindow about bytewax

[davidselassie]

Thank you for this report.

Fixing this is going to require a large change to our current naive windowing model and is an oversight in our initial design of the internal windowing machinery. Currently we assume that window assignment is static and can never change and is immediately passed to windowing logic for that window for processing. Session windows and watermarks interact so that adding out-of-order data means that it's possible that a window assignment for a previous data point is no longer correct when out-of-order data arrives (even if not "late" and before the watermark).

E.g. You want to calculate 5 min session windows. Assume the watermark is at 12:50 PM and does not advance through this example. A data point arrives with timestamp 1:00 PM; it is assigned window ID 1 and is passed to the ID 1 logic for processing. A data point then arrives with timestamp 1:06 PM; it is assigned window ID 2 because it has a >5 min gap, and is passed to the ID 2 logic for processing. Then a data point arrives with timestamp 1:03 PM; (in the current logic) it is assigned to window ID 1 because it is <5 min gap and then passed to the window ID 1 logic for processing.

This is correct but incomplete and inconsistent: Somehow the 1:06 PM data point should be "re-assigned" to the ID 1 window because the new out-of-order data point at 1:03 PM causes it to in total be in the same session as the initial 1:00 PM point, even though it initially got an ID 2. The current internal windowing API does not have the capability to do this, nor do I think that that is necessarily the correct design. It is also possible to do something like "buffer items until the window is closed¹ and then process all at once". It's also possible to require that window logic be always phrased as reductions so windows can be combined. We'll have to spend some time figuring out if there's a unifying way to re-design the internal interfaces to allow all windowers to be implemented in the same way.

I recommend this work be included as part of the "move windowing operators into Python" work as to not tee this up to be done twice.

---

I'll try to think if there are some more immediate mitigations you can do to still implement a generally-correct session window join, but I'm not sure there are.

Footnotes

1. I'm actually not sure what the definition of "closed" is in this sense and it might require custom logic per-windowing type. E.g. in session windowing you need to take into account the gap parameter to know how far past the watermark you should wait to know all window assignments are final; but that's not the same logic for all windowing types. ↩

[davidselassie]

Sorry accidental autoclose. This is not fixed.

[davidselassie]

This will be fixed with the next major release due to #433 which added "window merging" features.