morningman opened a new pull request, #67576:
URL: https://github.com/apache/doris/pull/67576
### What problem does this PR solve?
Problem Summary:
`FlightSqlChannel` had `getRemoteIp()` and `getRemoteHostPortString()`
stubbed out as `0.0.0.0` and
`0.0.0.0:0`, and `FlightSqlConnectContext` routed every client-address
accessor through them. So an
Arrow Flight SQL session reported `0.0.0.0:0` everywhere an operator looks
for one:
- the `Host` column of `SHOW PROCESSLIST` and of
`information_schema.processlist`;
- the audit log's `client_ip` (`AuditLogHelper` reads `ctx.getClientIP()`);
- the `kill query from ...` and connection-timeout warnings in `fe.log`.
With every Flight session showing the same placeholder, there was no way to
tell where one came
from — which client to talk to, which one to `KILL`.
The address is already resolved and already on the session:
`FlightRemoteIpServerStreamTracer`
captures it from the gRPC transport when the bearer token is issued, and
`FlightSessionsManager.buildConnectContext()` stores it via `setRemoteIP()`.
This PR reports that,
falling back to the tracer's `0.0.0.0` sentinel when the address could not
be resolved. The two
placeholder methods on `FlightSqlChannel` have no callers left and are
removed.
Only the address is reported, not the `host:port` pair MySQL reports: a
Flight session has no stable
peer port, because each gRPC call of a session may arrive on its own
connection. A port that changes
under the operator is worse than no port.
### Release note
An Arrow Flight SQL session now shows the real client address in `SHOW
PROCESSLIST`,
`information_schema.processlist` and the audit log's `client_ip`, instead of
the placeholder
`0.0.0.0:0`.
### Check List (For Author)
- Test
- [x] Regression test
- [x] Unit Test
New `FlightSqlConnectContextClientIpTest` (the session's accessors and the
`Host` column of
`ThreadInfo.toRow()`, plus the unresolved-address fallback) — with the
other Flight FE tests,
45 tests, 0 failures, 0 errors.
New
`regression-test/suites/arrow_flight_sql_p0/test_processlist_client_ip.groovy`:
over a Flight
connection it finds its own row in `SHOW PROCESSLIST`, asserts the host is
not the placeholder,
and cross-checks it against `information_schema.processlist` (served by a
different code path, the
BE schema scanner). Ran the whole `arrow_flight_sql_p0` directory on a
local cluster: 6 suites, 0
failed; the new suite logged `arrow flight session: id=19, host=127.0.0.1`.
- Behavior changed:
- [x] Yes. A Flight session's client address is now the real one
everywhere it is displayed;
it used to be `0.0.0.0:0`. Unlike a MySQL connection, it carries no
`:port` suffix.
- Does this need documentation?
- [x] No.
### Check List (For Reviewer who merge this PR)
- [ ] Confirm the release note
- [ ] Confirm test cases
- [ ] Confirm document
- [ ] Add branch pick label
🤖 Generated with [Claude Code](https://claude.com/claude-code)
https://claude.ai/code/session_01CCAMVmoWN2MGVVsSRDCf2p
--
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]
