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

   ## Which issue does this PR address?
   
   Relates to #3776 (Found while reviewing)
   
   ## Rationale
   
   The synchronous getters on the Python `IggyConsumer` took the consumer mutex 
with `blocking_lock()` while holding the GIL, and `consume_messages` holds that 
mutex for the whole consumption run. Reading an attribute during consumption 
hung the interpreter; reading one from a callback panicked inside the Tokio 
runtime. Neither is recoverable from Python.
   
   ```python
   consume = consumer.consume_messages(handle, shutdown_event)
   print(consumer.name())   # never returns
   ```
   
   ## What changed?
   
   None of those getters need exclusive access. `name`, `stream` and `topic` 
are fixed at construction, so the Python wrapper now snapshots them. The 
partition id and offsets live behind `Arc`s in the Rust SDK, which had no way 
to hand them out.
   
   The Rust SDK gains `IggyConsumerState`, a cheap cloneable view over that 
shared state, reachable via `IggyConsumer::state()`. `IggyConsumer` owns one 
and delegates its own `partition_id()` / `get_last_consumed_offset()` / 
`get_last_stored_offset()` to it, so there is a single implementation rather 
than two. The Python wrapper holds a clone and reads metadata without ever 
taking the lock.
   
   Nothing in the Rust public API changed shape. On the Python side `stream()` 
and `topic()` no longer return a `PyResult`, since the conversion now happens 
once at construction; the generated stub is unchanged.
   ## Local Execution
   
   - Passed 
   - Pre-commit hooks ran 
   
   ## AI Usage
   
   1. Which tools? Claude
   2. Scope of usage? help implement and write PR description
   3. How did you verify the generated code works correctly?  Ran the Python 
test suite against a real server
   4. Can you explain every line of the code if asked? Yes, all the changes are 
checked by the human.
   


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