[Prism] Drain behavior

[damondouglas]

What needs to happen?

Under #29669

The following uses an example driven approach via gherkin syntax to describe drain behavior.

Scenario: pipeline reads from Pub/Sub

Given pipeline reads from Pub/Sub subscription
  And more messages remain in the subscription
 When I trigger a drain
 Then no more mesages are read from the Pub/Sub subscription
  And the pipeline processes remaining messages read before the drain was triggered

Scenario: pipeline reads from file system

Given pipeline reads from a filesystem
  And more files are yet to be read by the pipeline
 When I trigger a drain
 Then the remaining files are read by the pipeline

Scenario: pipeline reads from Pub/Sub and reads from file system into a side input

Given pipeline reads from Pub/Sub subscription
  And more messages remain in the subscription
 When I trigger a drain
 Then no more mesages are read from the Pub/Sub subscription
  And the remaining files are read by the pipeline into the side input
  And the pipeline processes remaining messages read before the drain was triggered

Scenario: pipeline writes to Pub/Sub topic

Given pipeline writes to Pub/Sub topic
 When I trigger a drain
 Then the pipeline continues writing to the topic until it proceses all remaining in-flight elements in the pipeline

[damondouglas]

@lostluck FYI

[lostluck]

Thanks for your patience. This is all largely correct.

Drain semantics are tricky since they only apply to unbounded pipelines, since the data there is most at risk of loss when a pipeline is terminated.

Eg. The scenario for Filesystems would only apply if the reads were triggered by a batch FileIO transform. Logically a runner is not aware of how differrent elements go together in bundles, so it's not possible to stop reading new files, if the runner has elements representing them still in flight. The transform isn't aware that it can drain (outside of unbounded restriction truncation, a transform isn't drain aware).

Conversely, if the file system reader were a Watch transform, then that's semantically an unbounded transform, and all already observed files would complete processing, but no new arrivals should occur, because a Watch Transform's restriction when truncated, should prevent that, and cause the transform to Stop.

The pipeline writes to Pub/Sub topic scenario is incorrect however. A sink/writer transform doesn't do anything in particular for a drain. It will continue to write all in flight elements destined for it, and not suddenly stop. It will only stop once there are no further inbound elements, because to do otherwise is to lose data.