fix: frontier freezes when updates in ValDistributor consolidate away - #834
Conversation
…r', when the input consolidates to nothing
ValDistributor consolidate awayValDistributor consolidate away
|
I'll check; you are right that there is an invariant that one needs to ship "the number of expected records" not "what they end up being once you compact them", or at least an int saying as much. Brb once I point some robots at it. |
|
Yup, looks good and makes sense. The only nuance I would add is that the |
|
Thanks for the quick review, and heads up about the status of the Mostly just experimenting at the moment, but if it goes further I would love to chat. |
|
Sounds great; and thank you for the bug report and fix! |
Hey Frank!
I ran into an issue with the columnar
ValDistributorthat caused my dataflow to hang, i.e. the frontier of an operator stopped advancing.As far as I (and Claude) understand, timely tracks the number of records emitted by an operator and all records consumed by the next downstream operator. timely considers
produced - consumed > 0as meaning "records still in flight" and thus it cannot advance the frontier.Issue
The
RecordedUpdatescontainer used byValDistributorconsolidates as records get pushed into the trie. The problem is when all of the per-workeroutputs consolidate to nothing.ValDistributoremits no messages and thus timely forever sees outstanding records on that edge.Fix
This PR adds a check for this specific case, and emits a single update whose
recordcount is the total number of input records. It also includes a regression test that exhibits the problem on today'smaster.