Trait ReplicationHook 

pub trait ReplicationHook: Send + Sync {
    // Provided methods
    fn before_apply(&self, _log: &ReplicationLog) -> Result<()> { ... }
    fn after_apply(&self, _log: &ReplicationLog) -> Result<()> { ... }
    fn on_replication_error(&self, _log: &ReplicationLog, _error: &Error) { ... }
    fn resolve_conflict(&self, _existing: &[u8], new: &[u8]) -> Result<Vec<u8>> { ... }
}

Trait for custom replication hooks

Implement this trait to add custom logic around replication events.

Provided Methods

fn before_apply(&self, _log: &ReplicationLog) -> Result<()>

Called before applying incoming replicated data

Return Err to reject the replication.

fn after_apply(&self, _log: &ReplicationLog) -> Result<()>

Called after successfully applying replicated data

fn on_replication_error(&self, _log: &ReplicationLog, _error: &Error)

Called when a replication operation fails

fn resolve_conflict(&self, _existing: &[u8], new: &[u8]) -> Result<Vec<u8>>

Custom conflict resolution

Only called if ConflictResolution::Custom is set. Return the data that should be written (either existing or new).

Hook Chaining

When multiple hooks are registered, they are applied sequentially:

• First hook receives: (existing_data, incoming_data)
• Second hook receives: (existing_data, first_hook_result)
• Third hook receives: (existing_data, second_hook_result)
• And so on…

The final hook’s result is what gets written to the database. This allows you to compose conflict resolution strategies.

Example

struct MergeHook;
impl ReplicationHook for MergeHook {
    fn resolve_conflict(&self, existing: &[u8], new: &[u8]) -> Result<Vec<u8>> {
        // Custom merge logic here
        Ok(merge_json(existing, new))
    }
}

Implementors