zhaohaidao opened a new issue, #125:
URL: https://github.com/apache/fluss-rust/issues/125

   ### Search before asking
   
   - [x] I searched in the 
[issues](https://github.com/apache/fluss-rust/issues) and found nothing similar.
   
   
   ### Please describe the bug 🐞
   
   ## Summary
   The C++ SDK example (`fluss_cpp_example`) intermittently hangs during table 
operations, most visibly while appending rows. The hang was reproducible and 
traced to an infinite loop in the Rust write path.
   
   ## Environment
   - Repo: fluss-rust
   - Example: `bindings/cpp/build/fluss_cpp_example`
   - Observed on macOS (arm64)
   
   ## Symptoms
   - Example sometimes stops after `Creating table with 3 buckets...` or during 
append/poll/drop.
   - `AppendWriter::append` blocks indefinitely on the C++ side.
   - RPC requests (e.g., `CreateTable`, `ProduceLog`) succeed, but the process 
can still hang.
   
   ## Debugging Timeline
   1. Added temporary RPC and write-path debug logs to confirm requests were 
sent/received.
   2. Captured lldb backtraces:
      - Main thread blocked in `AppendWriter::append` waiting for write 
completion.
      - One tokio worker stuck in 
`RecordAccumulator::drain_batches_for_one_node`.
      - All other workers parked (idle).
   3. Added targeted logs around `RecordAccumulator::append` and 
`drain_batches_for_one_node`.
   4. Observed repeated `drain` iterations with empty buckets and no exit, 
indicating a tight loop.
   
   ## Root Cause
   `RecordAccumulator::drain_batches_for_one_node` had a `continue` on empty 
bucket that skipped the loop termination check:
   
   ```
   if batch_lock.is_empty() {
       continue;
   }
   ...
   if current_index == start {
       break;
   }
   ```
   
   When the loop returned to `start` and the bucket was empty, the `continue` 
prevented the `break`, causing an infinite loop. This blocked the Sender and 
kept `ResultHandle::wait()` pending.
   
   ### Solution
   
   ## Fix
   Refactored the loop to avoid `continue` before the termination check. Empty 
buckets are now handled without skipping the `current_index == start` break 
condition. The batch pop is performed only if the deque is non-empty, and the 
loop terminates correctly.
   
   ## Verification
   After the fix, the C++ example completes reliably:
   - `AppendWriter::append` returns
   - `ProduceLog` responses are handled
   - Example finishes with expected output (write, scan, list offsets, batch 
subscribe)
   
   ### Are you willing to submit a PR?
   
   - [ ] 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: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to