lostluck commented on issue #30250: URL: https://github.com/apache/beam/issues/30250#issuecomment-1939204896
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. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
