databendlabs / openraft / 18936702743

88%

push

github

change: avoid Vec allocation in RaftStateMachine::apply()

Replace the Vec-returning API with a callback-based approach that
enables zero-allocation response handling. This allows state machines
to send responses immediately after applying each entry, rather than
buffering them in a Vec.

Previously, `RaftStateMachine::apply()` required returning a Vec of
responses, which meant:
1. Allocating memory for the Vec
2. Collecting all responses before returning
3. Extra clones and memory overhead

The new API uses `EntryResponder` and `ApplyResponder` to:
1. Pair each entry with its responder as a tuple
2. Allow immediate response sending via `responder.send()`
3. Eliminate Vec allocation overhead

Changes:

- Add `EntryResponder<C>` type alias: `(EntryOf<C>, ApplyResponder<C>)`
- Add `ApplyResponder<C>` public wrapper for sending responses
- Change `RaftStateMachine::apply()` signature:
  - Input: `IntoIterator<Item = EntryResponder<C>>` (was `C::Entry`)
  - Return: `Result<(), StorageError<C>>` (was `Result<Vec<C::R>, ...>`)
- Add internal `EntryResponderBuilder` for constructing `EntryResponder`

- Fix: #1459
- Fix: #1266

Upgrade tip:

Update your `RaftStateMachine::apply()` implementation:

```rust
// Before (0.9.x):
async fn apply<I>(&mut self, entries: I) -> Result<Vec<Response>, StorageError<C>>
where I: IntoIterator<Item = C::Entry> {
    let mut responses = Vec::new();
    for entry in entries {
        let response = /* process entry */;
        if let Some(responder) = responder {
            responses.push(response);
        }
    }
    Ok(responses)
}

// After (0.10.0):
use openraft::storage::EntryResponder;

async fn apply<I>(&mut self, entries: I) -> Result<(), StorageError<C>>
where I: IntoIterator<Item = EntryResponder<C>>
{
    for (entry, responder) in entries {
        let response = /* process entry */;
        if let Some(responder) = responder {
            responses.push(response);
        }
    }
    Ok(())
}
```

Key changes:

- ... (continued)

67 of 67 new or added lines in 7 files covered. (100.0%)

12365 of 13518 relevant lines covered (91.47%)

137576.29 hits per line