yummyPancake2607 opened a new pull request, #4065:
URL: https://github.com/apache/iggy/pull/4065

   The Rust SDK's SystemClient trait can report the currently connected client 
and enumerate all connected clients, but the Python SDK exposed none of it, 
leaving operators unable to see connection state that every other SDK already 
surfaces.
   
   Adds ClientInfo/ClientInfoDetails/ConsumerGroupInfo bindings following the 
user.rs pattern, wires get_me/get_client/get_clients onto IggyClient, and 
re-exports ClientInfo/ConsumerGroupInfo from the SDK prelude since only 
ClientInfoDetails was public before.
   
   ## Which issue does this PR address?
   
   Closes #4015
   
   ## Rationale
   
   Every other Apache Iggy SDK exposes `get_me`/`get_client`/`get_clients` from 
`SystemClient`, so a Python operator has no way to see which client they're 
connected as or what else is connected to the server — parity gap tracked under 
#3893, this issue's specific ask.
   
   ## What changed?
   
   `foreign/python/src/client_info.rs` gained real bindings for `ClientInfo`, 
`ClientInfoDetails`, and `ConsumerGroupInfo` — `inner`-wrapped structs with 
`From<Rust*>` conversions and `#[gen_stub_pymethods]` getters, mirroring 
`user.rs` rather than the bare-struct copy that was there before. 
`address`/`transport` return `&str` instead of cloning, and `consumer_groups` 
documents that each read allocates a fresh list.
   
   `IggyClient` in `client.rs` gained `get_me`, `get_client`, `get_clients`, 
placed right after `ping` (get_me needs authentication only; 
get_client/get_clients need `read_servers` or `manage_servers` and raise 
`Unauthorized` without it — both stated explicitly in the docstrings since the 
wire error is generic).
   
   `core/sdk/src/prelude.rs` now re-exports `ClientInfo` and 
`ConsumerGroupInfo` alongside the already-exported `ClientInfoDetails` — needed 
for `get_clients()`'s return type to be nameable from the Python crate without 
pulling in `iggy_common` directly (which would have re-introduced a version pin 
`bump-version.sh` doesn't touch).
   
   `tests/test_client_info.py` covers: `get_me` against the fixture's TCP 
transport and logged-in user id, `get_me` reporting a joined consumer group 
(with a helper that forces stream/topic/group ids to be pairwise distinct, 
since a fresh stream would otherwise hand its first topic and group the same id 
and let a swapped field mapping pass silently — verified by manually swapping 
`stream_id`/`topic_id` and confirming the test fails), `get_clients` containing 
the caller's own entry, `get_client` matching `get_me` and returning `None` for 
an unknown id, and the `read_servers` permission gate (granted and denied 
cases).
   
   ## Local Execution
   
   - Passed
   - Pre-commit hooks not ran — HawkEye isn't installed locally, so I ran the 
equivalent steps directly instead of through `prek`: `cargo fmt --all --check`, 
`cargo clippy --all-targets -- -D warnings` (Python crate, plus `-p iggy` for 
the prelude change), `ruff check`/`ruff format --check`/`pyrefly check .`, and 
`cargo run --bin stub_gen` to confirm `apache_iggy.pyi` has no drift. Full 
`pytest tests/` (excluding the Docker-only `test_tls.py`) passed against a real 
`iggy-server` instance: 510 passed.
   
   ## AI Usage
   
   1. Claude Code (Claude Opus).
   2. Full implementation: the binding module, the three client methods, the 
prelude re-export, and the test file were AI-generated, following the existing 
`user.rs`/`get_user`/`get_users` patterns in this crate.
   3. Verified by running the code, not just reading it: built and ran a real 
`iggy-server`, exercised every new method and the permission gate against it, 
and for the stream/topic/group id-collision risk specifically, mutated the 
field mapping (swapped `stream_id`/`topic_id`) and confirmed the test suite 
catches it before reverting.
   4. Yes.


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

Reply via email to