[FLINK-39846][tests] Restore IPv6 guard and config in IPv6HostnamesITCase under AdaptiveScheduler

[MartijnVisser]

What is the purpose of the change

The JUnit5 migration (FLINK-39124, #27669) converted IPv6HostnamesITCase from a JUnit4 @Rule MiniClusterWithClientResource(... .setConfiguration(getConfiguration()) ...) to a static @RegisterExtension MiniClusterExtension(...) with a hardcoded configuration, dropping the call to getConfiguration(). That method (a) bound the cluster to a local IPv6 address and (b) skipped the test (via an IPv6 assumption) when no non-loopback IPv6 address is available.

After the migration getConfiguration() became dead code, so the test runs unconditionally and without IPv6 configuration, and fails under the AdaptiveScheduler because the job uses GlobalWindows.createWithEndOfStreamTrigger() -- a blocking (non-pipelined) data exchange the AdaptiveScheduler does not support. It has failed every nightly test_cron_adaptive_scheduler build on master since ~2026-04-15. release-2.0/release-2.1 still call getConfiguration(), so they skip the test when IPv6 is unavailable and stay green.

This restores the IPv6 configuration and the skip behavior, and additionally tags the test so it is excluded from the adaptive profile even when an IPv6 address is available.

Brief change log

• Resolve the IPv6 address once in a nested holder class (so it does not depend on static field declaration order) and configure the MiniClusterExtension with it when present (restoring IPv6 binding).
• Add a class-level @EnabledIf("hasBindableIpv6Address") condition so the class is skipped before the MiniCluster is started when no usable IPv6 address is available (this is evaluated before the extension's beforeAll, unlike an in-test assumeThat).
• Tag the test with @Tag("org.apache.flink.testutils.junit.FailsWithAdaptiveScheduler"), since the blocking exchange is genuinely incompatible with the AdaptiveScheduler.

Verifying this change

This change is already covered by the existing IPv6HostnamesITCase.testClusterWithIPv6host. It was verified locally:

• Default scheduler on a host with a non-loopback IPv6 address: Tests run: 1, Failures: 0, Errors: 0 (the test again exercises IPv6 binding); on a host without IPv6 the class is disabled by @EnabledIf (skipped).
• -Penable-adaptive-scheduler: the test is excluded by the tag (Tests run: 0), so the adaptive nightly leg is green.
• checkstyle:check and spotless:check pass.

Note on coverage: the IPv6 binding is exercised only under the default scheduler on an IPv6-capable host. Under the adaptive profile the test is excluded by design (the blocking exchange cannot run there); this exclusion is intentional and tracked in FLINK-39846, it should not be removed without also reworking the job to use a pipelined exchange.

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 (test-only change)
• 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 (Claude Code (Claude Opus 4.8))

Generated-by: Claude Code (Claude Opus 4.8)

[flinkbot]

CI report:

• 8ece954 Azure: FAILURE

Bot commands

The @flinkbot bot supports the following commands:

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

[1996fanrui]

Why widen to LinkageError? This silently turns a class-loading failure into a "skip" — was it actually hit somewhere, or can it stay catch (Exception e)?

[MartijnVisser]

Good point, reverted to catch (Exception e) in 8ece954. The LinkageError was speculative (never actually observed) and, as you say, would turn a genuine class-loading failure into a silent skip — if RpcSystem.load() ever throws one it should surface, not be swallowed. Kept the LOG.debug so a skip stays explainable.

[1996fanrui]

Thanks for the fix and update, LGTM