[I] [rust] Writes to different tables wait for unrelated responses [fluss]

["naivedogger (via GitHub)" <gi...@apache.org>]

naivedogger opened a new issue, #4476:
URL: https://github.com/apache/fluss/issues/4476

   ### Search before asking
   
   - [x] I searched in the [issues](https://github.com/apache/fluss/issues) and found nothing similar.
   
   ### Motivation
   
   When several writers share a Rust `Connection`, batches for different tables can be drained to the same tablet server. `Sender::send_write_request()` groups those batches by table, but then awaits `send_and_handle_response()` inside the per-table loop. The next table's request is not sent until the previous table's response handling finishes.
   
   This introduces head-of-line blocking between otherwise independent tables. A delayed response for one table can prevent another ready table from being sent, even when its buckets satisfy their own in-flight limits. The dependency is in RPC scheduling, not user callback execution, so it also affects writes without callbacks.
   
   A deterministic reproduction uses two tables on one established RPC connection:
   
   1. Queue a batch for each table before draining.
   2. Let the mock server receive the first request and withhold its response.
   3. Check whether the second table's request can arrive and complete while the first is still pending.
   
   Currently, the second request cannot be dispatched from that drained group. It should be able to make progress independently, without relaxing the existing per-bucket sequence or in-flight constraints. Java already issues these per-table RPCs asynchronously rather than awaiting each response in the loop.
   
   ### Solution
   
   Schedule independent table requests independently after the existing drain and in-flight checks. Keep response ownership and errors scoped to each request. Implementation details and local measurements will be included in the accompanying PR.
   
   ### Anything else?
   
   This concerns scheduling for existing per-table writers, not the new multi-table writer API proposed in #3961. It does not claim to fix failover or metadata-refresh stalls.
   
   ### Willingness to contribute
   
   - [x] I'm willing to submit a PR!
   


-- 
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: issues-unsubscribe@fluss.apache.org.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org