Should use allowedLateness from downstream computations in ReduceFnRunner
- Dominant language
- Java
- Stars
- 8.7k
- Forks
- 4.7k
- Avg merge
- 1d 20h
- Merged PRs (30d)
- 196
Description
Much of the reasoning about holds, late data and final panes in ReduceFnRunner assume the current getAllowedLateness is an upper bound of the getAllowedLateness of all downstream computations.
There is currently no test that this is indeed the case.
It may be much simpler (for us and our users) to have a global allowed lateness setting.
Imported from Jira [BEAM-237](https://issues.apache.org/jira/browse/BEAM-237). Original Jira may contain additional context.
Reported by: mshields822.
Contributor guide
Research direction
Start by reading ReduceFnRunner and tracing how getAllowedLateness is obtained for downstream computations. Review the linked Jira issue for context, then determine whether the intended outcome is a regression test for the assumed lateness relationship or a global allowed-lateness setting. Done requires a decided behavior and coverage for it.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- stream-processing
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100