[hotfix] Add null check for currentReader in pauseOrResumeSplits

[xccui]

What is the purpose of the change

Add null check for pauseOrResumeSplits to avoid NPE

Brief change log

Added null check for currentReader in pauseOrResumeSplits().

Verifying this change

Please make sure both new and modified tests in this PR follow the conventions for tests defined in our code quality guide.

This change is a trivial rework / code cleanup without any test coverage.

Does this pull request potentially affect one of the following parts:

• Dependencies (does it add or upgrade a dependency): (yes / no)
• The public API, i.e., is any changed class annotated with @Public(Evolving): (yes / no)
• The serializers: (yes / no / don't know)
• The runtime per-record code paths (performance sensitive): (yes / no / don't know)
• Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Kubernetes/Yarn, ZooKeeper: (yes / no / don't know)
• The S3 file system connector: (yes / no / don't know)

Documentation

• Does this pull request introduce a new feature? (yes / no)
• If yes, how is the feature documented? (not applicable / docs / JavaDocs / not documented)

[flinkbot]

CI report:

• 80cdd5a Azure: SUCCESS

Bot commands

The @flinkbot bot supports the following commands:

• @flinkbot run azure re-run the last Azure build

[Copilot]

Pull Request Overview

This PR adds a null safety check to the pauseOrResumeSplits method in HybridSourceReader to prevent potential NullPointerException when the method is called before any source reader has been initialized.

• Adds null check before delegating to the current reader's pauseOrResumeSplits method

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[davidradl]

if it is null, should we error?
Would it fail later if we do not error here ?
Can we get an empty collection here - that we could also check for?

[xccui]

It's normal for the currentReader to be null. I'm just not sure if this method will be invoked when it happens. So just in case.

[davidradl]

I had a look at the non test code, I see

flink/flink-runtime/src/main/java/org/apache/flink/streaming/api/operators/SourceOperator.java

Line 767 in 0ffacdc

pauseOrResumeSplits(splitsToPause, splitsToResume);

flink/flink-runtime/src/main/java/org/apache/flink/streaming/api/operators/SourceOperator.java

Line 727 in 0ffacdc

pauseOrResumeSplits(Collections.singletonList(splitId), Collections.emptyList());

as the 2 callers that end up in this code - both of whom call this with a non null. I suggest we do not need the null check as this parameter is never null. Did I miss anything?

[xccui]

Yes. Actually we had used the version without the null check for several months internally and didn't hit any issues. It implies the null check could be redundant. However, potentially more code will use this method in the future. So adding the check would be a defensive measure (I actually forgot to push this commit to my previous PR). I'm fine with both.