LuciferYang opened a new pull request, #7693:
URL: https://github.com/apache/kyuubi/pull/7693
### Why are the changes needed?
Closes #7692.
`testFindLocalInetAddress` branched on whether `InetAddress.getLocalHost()`
was loopback and, in the loopback case, asserted that `findLocalInetAddress()`
returns something else. The method has a third outcome the test did not account
for: when the interface scan finds no address that is neither loopback nor
link-local, it logs and returns the loopback address it started from. On such a
host the assertion compares that address against itself and fails.
The test now branches on the outcome rather than on the starting address
alone. When a replacement was scanned off an interface, it asserts the address
belongs to an interface and is not link-local. Otherwise it asserts the
original address came back unchanged, and when that address is loopback it also
asserts no interface offered a usable one, which is what separates a correct
fallback from a scan that silently returned loopback. The helper it calls only
asks whether any interface address is neither loopback nor link-local; it does
not repeat the selection rules.
Three decisions inside the method still have no assertion behind them, and
are left for a follow-up: the host-name and IPv6 scope stripping, the IPv4
preference within the chosen interface, and the reversal that decides which
interface wins when several have candidates. Only the first is writable against
the current API, and on a host that picks an IPv4 address it asserts nothing;
the other two need a seam that lets a test supply the interface list.
### How was this patch tested?
```
build/mvn -o test -pl kyuubi-util -am -DwildcardSuites=none
-Dtest=JavaUtilsTest
build/mvn -o spotless:check -pl kyuubi-util
```
That run does not reach the branch this fixes, because `getLocalHost()`
resolves to a routable LAN address here. The fixed branch was exercised in a
container that reproduces the failing host, where `getLocalHost()` and
`findLocalInetAddress()` are both `127.0.0.1`:
```
docker run --rm --network none --hostname loopbox --add-host
loopbox:127.0.0.1 \
-v ~/.m2:/root/.m2 -v $PWD:/src -w /src eclipse-temurin:17-jdk \
build/mvn -o test -pl kyuubi-util -am -DwildcardSuites=none
-Dtest=JavaUtilsTest
```
`-o` works with no network because the mounted `~/.m2` and the
already-extracted `build/apache-maven-*` in the checkout are all it needs.
Master's test fails there with `expected: not equal but was:
<loopbox/127.0.0.1>`; this one passes.
Four mutations of `findLocalInetAddress` show the assertions are not
vacuous. Each turns the test red, and the first three were reached by mapping
the host name to `127.0.0.1` with `-Djdk.net.hosts.file`:
- dropping `!addr.isLinkLocalAddress()` from the candidate filter, so the
method returns a link-local address: `expected: <false> but was: <true>`
- returning an address not bound to this host (`8.8.8.8`) instead of
`strippedAddress`: `expected: not <null>`
- dropping the candidate filter entirely, so the scan returns `127.0.0.1`
and the test takes the other arm: `expected: <false> but was: <true>`, from the
assertion that there was nothing to find
- replacing `if (address.isLoopbackAddress())` with `if (true)` so the scan
always runs, no hosts file needed: the pass-through assertion fails because the
scanned address differs from what `getLocalHost()` returned
Whether any of this runs on CI depends on how `getLocalHost()` resolves on a
GitHub runner, which I did not check: a routable answer means the test takes
the same `assertEquals` as master, a `127.0.1.1` answer means it takes the
replacement arm. The fallback path is certainly not reached there, otherwise
master would be failing today.
### Was this patch assisted by generative AI tooling?
Assisted-by: Claude Opus 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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
