harish876 opened a new issue, #220:
URL: https://github.com/apache/incubator-resilientdb/issues/220

   # Description: Sequence Number Resets on Process Restart
   
   ## Summary
   
   Fixed a critical bug where sequence numbers (`next_seq_`) were reset to 1 on 
process restart, violating PBFT consensus safety guarantees and potentially 
causing duplicate sequence number assignment to different transactions.
   
   ## Problem Statement
   
   ### The Bug
   When a ResilientDB replica process restarts, the sequence number counter 
(`next_seq_`) is initialized to 1 instead of being restored from persistent 
storage. This causes the system to reuse sequence numbers that were already 
assigned to previous transactions.
   
   ```cpp
   // Before fix - always reset to 1
   uint64_t next_seq_ = 1;  // In message_manager.h
   ```
   
   ### Impact
   - **Duplicate Sequence Numbers**: Different transactions could be assigned 
the same sequence number after restart
   - **State Divergence**: Replicas could execute different transactions with 
identical sequence numbers
   - **PBFT Violation**: Breaks consensus protocol safety guarantees that 
require monotonically increasing sequence numbers
   
   ### Example Scenario
   ```
   Timeline:
   1. Replica commits transactions seq=[1, 2, 3] to persistent storage (leveldb)
   2. Replica process restarts
   3. next_seq_ resets to 1 (BUG!)
   4. Primary assigns seq=2 to a NEW request (different from original seq=2)
   5. Result: State inconsistency across replicas
   ```
   
   ## Root Cause
   
   The sequence number was only being updated during:
   1. **Recovery requests**: In `Commitment::ProcessProposeMsg()` when handling 
recovery messages
   2. **View change**: In `ViewChangeManager::ProcessViewChangeMsg()`
   3. GetMaxSeq in chain state does not get set during recovery and is at 0 by 
default during restart
   
   There was **no recovery on normal startup** to restore the sequence number 
from persistent storage.


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