Skip to content

Conversation

utaal
Copy link
Member

@utaal utaal commented May 12, 2020

It's unsafe to create capabilities based on the input frontier of the operator: a negative incoming point-stamp change may be in flight, which would cause a race condition downstream.

I'm a little short on time right now, but I'd be happy to provide more details on the race condition. From preliminary testing, no operator violates this stricter requirement.

This was found as part of the verification effort at ETH, by @saradecova.

It's unsafe to create capabilities based on the input frontier of the operator: a negative point-stamp change may be in flight, which would cause a race condition downstream
@frankmcsherry
Copy link
Member

Seems legit! When you all have more time I'd be interested in the race, and the implications to the method (this seems to now catch more error cases, but it sounds like none of the implementors were screwing this up; is this more about writing down the correct statement about progress validation than changing the system's behavior?)

@frankmcsherry frankmcsherry merged commit b42542e into TimelyDataflow:master May 12, 2020
@utaal utaal changed the title WIP: fix validate_progress in subgraph fix validate_progress in subgraph May 13, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants