There's a dangerous edge-case in the deletion logic due to the inter-dependence of fuzzy and finalized chains. The deletion logic is careful not to delete the latest approved attestation for all chains. However, in an edge-case, the latest approved attestation for a fuzzy chain might be overridden by a finalized attestation that gets deleted. Consider the following case:
We have a pending fuzzy attestation A for block offset 10
A finalized attestation B for block offset 10 is approved, we update A to be "overridden" by B
A finalized attestation C for block offset 11 is approved
Deletion logic runs (assume all attestations were created long enough ago to be considered for deletion)
The latest attestation offsets we will calculate are 10 for the fuzzy chain, and 11 for the finalized chain. As a result, we will not delete A (it's a fuzzy attestation with offset = 10), and will not delete C (it's a finalized attestation with offset = 11), but we WILL delete B (since, from the perspective of the finalized chain, it's stale). This is a bug, since A links to B, but B has now been deleted. It leads to crashes such as this:
I'm not sure what the right thing to do here is. What I would like to do is to change the latestAttestation method to always check the finalized chain (when called with a fuzzy chain) for a later attestation (and return that if found). This is the correct value to be considered as the "latest" attestation. However, I'm concerned that some callers of this method may be confused by this change of behaviour.
There's a dangerous edge-case in the deletion logic due to the inter-dependence of fuzzy and finalized chains. The deletion logic is careful not to delete the latest approved attestation for all chains. However, in an edge-case, the latest approved attestation for a fuzzy chain might be overridden by a finalized attestation that gets deleted. Consider the following case:
A
for block offset 10B
for block offset 10 is approved, we updateA
to be "overridden" byB
C
for block offset 11 is approvedThe latest attestation offsets we will calculate are 10 for the fuzzy chain, and 11 for the finalized chain. As a result, we will not delete
A
(it's a fuzzy attestation with offset = 10), and will not deleteC
(it's a finalized attestation with offset = 11), but we WILL deleteB
(since, from the perspective of the finalized chain, it's stale). This is a bug, sinceA
links toB
, butB
has now been deleted. It leads to crashes such as this:I'm not sure what the right thing to do here is. What I would like to do is to change the
latestAttestation
method to always check the finalized chain (when called with a fuzzy chain) for a later attestation (and return that if found). This is the correct value to be considered as the "latest" attestation. However, I'm concerned that some callers of this method may be confused by this change of behaviour.