[Feature Request]: Wait.on for Go SDK
- Dominant language
- Java
- Stars
- 8.7k
- Forks
- 4.7k
- Avg merge
- 1d 20h
- Merged PRs (30d)
- 196
Description
### What would you like to happen?
I'd like to port the Wait.On functionality of Java to the Go SDK, so that runtime ordering constraints can be added between transforms without requiring modification of the transforms.
I often have operations which rely on side-effects (eg database writes having completed, GCS storage, BigTable updates, etc). In order to sequence these operation in Go, I end up wiring in completion signals manually into producers and then side-inputs into consumers. This is effectively a manual implementation of `wait.On` which reduces composability of the operations since it means the shape of the operation has to be modified for the particular situation.
The goal would be to provide a transforms/wait package containing an `On` method:
```go
// To finish writing each window to one database before writing it
// to another:
firstWriteResults := beam.ParDo(s, writeToFirstDB, data)
delayed := wait.On(s, data, firstWriteResults)
beam.ParDo0(s, writeToSecondDB, delayed)
```
Where `On` would look like this:
```go
// On returns col unchanged, but delays each main window until its mapped window
// has closed in every signal.
//
// With no signals, On validates s and col and returns col directly. Otherwise,
// it panics at pipeline construction time for an invalid scope or PCollection,
// CoGBK inputs, or session-windowed signals.
func On(s beam.Scope, col beam.PCollection, signals ...beam.PCollection) beam.PCollection {
```
### Issue Priority
Priority: 2 (default / most feature requests should be filed as P2)
### Issue Components
- [ ] Component: Python SDK
- [ ] Component: Java SDK
- [x] Component: Go SDK
- [ ] Component: Typescript SDK
- [ ] Component: IO connector
- [ ] Component: Beam YAML
- [ ] Component: Beam examples
- [ ] Component: Beam playground
- [ ] Component: Beam katas
- [ ] Component: Website
- [ ] Component: Infrastructure
- [ ] Component: Spark Runner
- [ ] Component: Flink Runner
- [ ] Component: Prism Runner
- [ ] Component: Twister2 Runner
- [ ] Component: Hazelcast Jet Runner
- [ ] Component: Google Cloud Dataflow Runner
Contributor guide
Research direction
Start by comparing Java's Wait.On implementation with the Go SDK's existing transform packages and the proposed transforms/wait package API. Trace how beam.Scope, beam.PCollection, windowing, and signal collections are validated. Done means a Go wait.On implementation provides the stated ordering behavior and construction-time validation, with tests covering signals, windows, invalid inputs, and the no-signal case.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go, java
- Domain
- data-engineering, distributed-systems
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100