MartijnVisser opened a new pull request, #29037:
URL: https://github.com/apache/flink/pull/29037

   ## What is the purpose of the change
   
   When a job is drained (bounded source finishing, or stop-with-savepoint 
--drain), `advanceToEndOfEventTime()` emits `Watermark.MAX_WATERMARK` directly 
into the operator chain output. However, `RecordWriterOutput#emitWatermark` and 
`ChainingOutput#emitWatermark` drop watermarks while the last announced 
`WatermarkStatus` is `IDLE`. A source whose last announced status was IDLE 
therefore never delivered the final MAX watermark, so downstream event-time 
timers and windows did not fire at end of job. This PR re-activates the output 
before emitting the final MAX watermark, the same pattern used by 
`TimestampsAndWatermarksOperator.WatermarkEmitter` and the table 
`WatermarkAssignerOperator`.
   
   ## Brief change log
   
   - `SourceOperatorStreamTask`, `SourceStreamTask`, and 
`MultipleInputStreamTask` now emit `WatermarkStatus.ACTIVE` before 
`Watermark.MAX_WATERMARK` in `advanceToEndOfEventTime()`; downstream outputs 
deduplicate the ACTIVE when already active.
   - The ACTIVE emission is skipped for tasks deployed as finished on restore: 
they never ran a source, their outputs were never idle, and 
`FinishedOnRestoreMainOperatorOutput` rejects watermark status events by design.
   - Added `SourceOperatorStreamTaskIdleDrainTest` (task-level: a source that 
goes IDLE and then finishes must drain `[IDLE, ACTIVE, MAX_WATERMARK, 
EndOfData]`) and `ChainingOutputIdleMaxWatermarkTest` (output-level: 
ACTIVE-then-MAX after IDLE is delivered; MAX alone while idle is dropped, 
characterizing the gate the fix works around).
   
   ## Verifying this change
   
   This change added tests and can be verified as follows:
   
   - `SourceOperatorStreamTaskIdleDrainTest` fails without the fix (drained 
output was `[WatermarkStatus(IDLE), EndOfData{mode=DRAIN}]`, no MAX watermark) 
and passes with it.
   - `ChainingOutputIdleMaxWatermarkTest` verifies the output-level contract.
   - Regression: `SourceOperatorStreamTaskTest` (incl. 
`testEmittingMaxWatermarkAfterReadingAllRecords`), `SourceStreamTaskTest`, 
`OneInputStreamTaskTest`, and `MultipleInputStreamTaskTest` all pass locally, 
confirming the ACTIVE emission does not break the non-idle and 
finished-on-restore drain paths.
   
   No existing tests were modified; both test classes are new.
   
   ## Does this pull request potentially affect one of the following parts:
   
     - Dependencies (does it add or upgrade a dependency): no
     - The public API, i.e., is any changed class annotated with 
`@Public(Evolving)`: no
     - The serializers: no
     - The runtime per-record code paths (performance sensitive): no 
(drain-time only)
     - Anything that affects deployment or recovery: JobManager (and its 
components), Checkpointing, Kubernetes/Yarn, ZooKeeper: yes — 
stop-with-savepoint --drain and end-of-input now emit a 
`WatermarkStatus.ACTIVE` before the final MAX watermark (deduplicated when 
already active); finished-on-restore tasks are exempted
     - The S3 file system connector: no
   
   ## Documentation
   
     - Does this pull request introduce a new feature? no
     - If yes, how is the feature documented? not applicable
   
   ---
   
   ##### Was generative AI tooling used to co-author this PR?
   
   - [X] Yes (please specify the tool below)
   
   Generated-by: Claude Code (Fable 5)
   


-- 
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]

Reply via email to