Skip to content

[FLINK-40503][core] Document effective idleness detection timing - #29039

Open
MartijnVisser wants to merge 1 commit into
apache:masterfrom
MartijnVisser:FLINK-40503
Open

[FLINK-40503][core] Document effective idleness detection timing#29039
MartijnVisser wants to merge 1 commit into
apache:masterfrom
MartijnVisser:FLINK-40503

Conversation

@MartijnVisser

Copy link
Copy Markdown
Contributor

What is the purpose of the change

Resolves FLINK-40503 by documenting when withIdleness actually takes effect. The WatermarksWithIdleness countdown is anchored at the first quiet periodic probe rather than at the last record, and the strict > comparison only fires at the next probe after the timeout is exceeded — so idleness is detected between idleTimeout and idleTimeout plus three watermark intervals after the last record (the worst case is attained when the timeout is an exact multiple of the auto-watermark interval). The javadoc previously implied detection at idleTimeout. The timing itself is intentionally left unchanged: silently changing detection timing in this area has a regression track record (cf. the FLIP-471 follow-ups).

Brief change log

  • Clarified the WatermarkStrategy#withIdleness javadoc and the WatermarksWithIdleness class doc with the precise detection-timing contract.
  • Added an equivalent paragraph to the "Dealing With Idle Sources" section of the event-time documentation (English page; updating the Chinese translation is a follow-up).
  • Added WatermarksWithIdlenessTimeoutTest, pinning the documented timing deterministically with a manual clock (timeout 10ms, probes every 5ms: not idle at the probes 11ms and 16ms after the last event, idle at the probe 21ms after it).

Verifying this change

This change added tests and can be verified as follows:

  • New deterministic WatermarksWithIdlenessTimeoutTest pins the documented detection timing.
  • Existing WatermarksWithIdlenessTest and WatermarkStrategyTest pass unchanged; no existing tests were modified.
  • Otherwise documentation-only; no behavior change.

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 (javadoc-only changes on WatermarkStrategy/WatermarksWithIdleness)
  • The serializers: no
  • The runtime per-record code paths (performance sensitive): no
  • Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Kubernetes/Yarn, ZooKeeper: no
  • 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 (clarifies existing documentation)

Was generative AI tooling used to co-author this PR?
  • Yes (please specify the tool below)

Generated-by: Claude Code (Fable 5)

The withIdleness javadoc suggested a partition is considered idle once no
records have arrived for idleTimeout, but WatermarksWithIdleness anchors its
countdown at the first quiet periodic probe (up to two watermark intervals
after the last record) and only switches to idle at the first probe strictly
exceeding the timeout, so detection can take up to idleTimeout plus three
watermark intervals. Document this actual behavior in the withIdleness and
WatermarksWithIdleness javadocs and in the idle-sources documentation
instead of changing the long-standing timing, and add a test pinning the
documented contract. The Chinese documentation page translates this section
and is left for a follow-up translation update.

Generated-by: Claude Code (Fable 5)
@flinkbot

flinkbot commented Aug 28, 2026

Copy link
Copy Markdown
Collaborator

CI report:

Bot commands The @flinkbot bot supports the following commands:
  • @flinkbot run azure re-run the last Azure build
@uros-b

uros-b commented Aug 29, 2026

Copy link
Copy Markdown
Member

LGTM, also kudos for nice testing

@github-actions github-actions Bot added the community-reviewed PR has been reviewed by the community. label Aug 30, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

community-reviewed PR has been reviewed by the community.

3 participants