Skip to content

[FLINK-40949][table-runtime] Update UnsliceAssigners NULL window exception message - #29424

Open
ykisana wants to merge 1 commit into
apache:masterfrom
ykisana:FLINK-40949
Open

ykisana wants to merge 1 commit into
apache:masterfrom
ykisana:FLINK-40949

Conversation

@ykisana

@ykisana ykisana commented Oct 7, 2026 •

Copy link
Copy Markdown

What is the purpose of the change

UnsliceAssigners.WindowedUnsliceAssigner should not have a NULL Window edge elements at either (windowStartIndex and windowStartIndex).

The current exception messaging (RowTime field should not be null.) isn't clear. We can make this more clear.

As per: FLINK-40949

Brief change log

  • CreateWindow in WindowedUnsliceAssigner has an updated message.
  • Old: RowTime field should not be null.
  • New: Both window start and window end should not be null.

Verifying this change

This is just a simple renaming of a string. We don't need explicit tests.

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

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

While AI was used before for PR desc/comments, current state of everything has no AI.

@flinkbot

flinkbot commented Oct 7, 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

@MartijnVisser

Copy link
Copy Markdown
Contributor

@ykisana For the next time, please wait with opening a PR until you're assigned to the Jira ticket

public long assignSliceEnd(RowData element, ClockService clock) {
if (element.isNullAt(sliceEndIndex)) {
throw new IllegalStateException(
"Slice end of a sliced input row is null. This is a bug.");

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

and what is call to action to user?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is a bug where?
flink, jdk, data, something else?
if I see it as a user how can this message help me?

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@snuyanzin I tried to follow bug messages in the rest of the repo 'This is a bug' is found in other places. It's an IllegalStateException. User can't do anything about it, bug on our side.
Updating to make this more clear though. Let me know if you have suggestions.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

User can't do anything about it, bug on our side.

if somewhere is NPE it is also bug in Flink, however I hardly tend to think that we need to insert tons of checks for NPE and for every tell that bug in our side because something is null...

Can we better try to understand cases we come here and why?

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@snuyanzin Yeah I agree. What's the process for that?
The ticket is for error messaging. I can do a follow up for looking at paths where we actually enter this state.

@ykisana
ykisana force-pushed the FLINK-40949 branch 2 times, most recently from d725e52 to 271fe01 Compare October 8, 2026 11:31

@snuyanzin snuyanzin left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Slice end of the input row is null, but it is always set by the upstream local window aggregate. This is a bug in Flink. Please file an issue.

this is false

after looking into that it is data/user issue rather than Flink bug

@snuyanzin

Copy link
Copy Markdown
Contributor

you can repro this with a query like

SELECT a, window_start, window_end, COUNT(*) FROM TUMBLE(TABLE src, DESCRIPTOR(rt), INTERVAL '5' SECOND) GROUP BY a, window_start, window_end

and then pass null for one of the values of rt

@ykisana ykisana changed the title [FLINK-40949][table-runtime] Fail with a clear error on NULL window bounds in windowed assigners [FLINK-40949][table-runtime] Don't report NULL window bounds as a NULL rowtime in WindowedUnsliceAssigner Oct 8, 2026
@ykisana

ykisana commented Oct 8, 2026

Copy link
Copy Markdown
Author

you can repro this with a query like

SELECT a, window_start, window_end, COUNT(*) FROM TUMBLE(TABLE src, DESCRIPTOR(rt), INTERVAL '5' SECOND) GROUP BY a, window_start, window_end

and then pass null for one of the values of rt

Thanks for looking into this and finding this! Yeah those code paths are still reachable. I was able to confirm with that query.

I believe WindowedUnsliceAssigner seeing NULL bounds is still unreachable, so I kept that in. Updated message following other examples in Flink.

@ykisana
ykisana requested a review from snuyanzin October 8, 2026 21:30
Comment on lines +232 to +235
throw new IllegalStateException(
"Window start or window end of the input row is null. "
+ "Both should be set by the upstream window operator. "
+ "This is a bug. Please file an issue.");

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why do we need this?
i'm pretty sure same story

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@snuyanzin At this stage we only expect valid windows, NULL rowtimes are rejected upstream. I believe this path is unreachable.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe this path is unreachable.

it is not a proof, need something more reliable as a proof

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe this path is unreachable.

also even if it is true, why do we even touch unreachable message?

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@snuyanzin I'm happy to leave message as is, or maybe just change to invalid state exception.
The purpose of ticket was clearer messaging: https://issues.apache.org/jira/browse/FLINK-40949

As for why it should be unreachable:

First Check:
http://github.com/apache/flink/blob/master/flink-table/flink-table-runtime/src/main/java/org/apache/flink/table/runtime/operators/wmassigners/WatermarkAssignerOperator.java#L136-L140

Second Check:
http://github.com/apache/flink/blob/master/flink-table/flink-table-runtime/src/main/java/org/apache/flink/table/runtime/operators/window/tvf/operator/UnalignedWindowTableFunctionOperator.java#L200-L205

If survived these checks, they get real bounds:
http://github.com/apache/flink/blob/master/flink-table/flink-table-runtime/src/main/java/org/apache/flink/table/runtime/operators/window/tvf/operator/WindowTableFunctionOperatorBase.java#L109-L121

Expected real bounds here:
http://github.com/apache/flink/blob/master/flink-table/flink-table-planner/src/main/scala/org/apache/flink/table/planner/plan/rules/physical/stream/StreamPhysicalWindowAggregateRule.scala#L111-L115

Thus real bounds here (which calls the function I changed):
http://github.com/apache/flink/blob/master/flink-table/flink-table-planner/src/main/java/org/apache/flink/table/planner/plan/nodes/exec/stream/StreamExecWindowAggregateBase.java#L77-L90

Note, your counter example only proved for SliceAssigners in a DIFFERENT path.
In this path, SliceAssigners also is expected real bounds.

UnsliceAssigners only lives here. It doesn't live in other paths without real bound pruning like here.

Let me know if I missed anything or how I should handle this.
Change exception? Or just leave as is? Ticket wanted something different here.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

change only message like

                throw new RuntimeException("Both window start and window end should not be null.");

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@snuyanzin updated, thanks for confirming. simple pr now

@ykisana
ykisana force-pushed the FLINK-40949 branch 2 times, most recently from c7f2459 to 874c00b Compare October 9, 2026 06:02
@snuyanzin

Copy link
Copy Markdown
Contributor

the commit/pr message is still vague

Don't report NULL window bounds as a NULL rowtime

reporting it as NOT NULL rowtime also satisfying this message however it is not true

@snuyanzin

Copy link
Copy Markdown
Contributor

also ci is red

@ykisana ykisana changed the title [FLINK-40949][table-runtime] Don't report NULL window bounds as a NULL rowtime in WindowedUnsliceAssigner [FLINK-40949][table-runtime] Update UnsliceAssigners NULL window exception message Oct 9, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants