Summary
In src/message_pool/msgpool/reorg.rs, the apply_head_change method swallows failures
from several critical operations by logging and continuing instead of propagating the error.
This means the caller always receives Ok(()) even when the pool has only been partially
updated, which can result in:
- Applied messages remaining in the pending pool (not removed)
- Reverted messages being silently dropped (not re-added)
- An inconsistent pool state that is difficult to detect or recover from
Affected locations
The following branches in apply_head_change log-and-continue instead of returning an error:
- ~Line 41-43:
self.api.load_tipset(ts.parents()) failure during revert
- ~Line 49-51: Block message fetch failure during revert
- ~Line 71-73: Block message fetch failure during apply
- ~Line 98-105: Message re-insertion failure after revert
Expected behavior
Each of these failures should propagate as a Result::Err with context describing which
operation failed and the relevant tipset/block identifier, so the caller can detect partial
failure and take corrective action.
References
Summary
In
src/message_pool/msgpool/reorg.rs, theapply_head_changemethod swallows failuresfrom several critical operations by logging and continuing instead of propagating the error.
This means the caller always receives
Ok(())even when the pool has only been partiallyupdated, which can result in:
Affected locations
The following branches in
apply_head_changelog-and-continue instead of returning an error:self.api.load_tipset(ts.parents())failure during revertExpected behavior
Each of these failures should propagate as a
Result::Errwith context describing whichoperation failed and the relevant tipset/block identifier, so the caller can detect partial
failure and take corrective action.
References
#7033