Now when sending a final proof to L1 we are setting the generating_since field of this proof to null before the L1 tx is confirmed (while waiting for this confirmation), this can cause an edge scenario where that proof can be "reused" by a prover to aggregate it to an existing aggregation. When this happened an "invalid" aggregation proof is created, since this proof contains a proof (batches) that are already verified, therefore, the aggregator never consider this proof as final to send it to L1 (since it starts from a batch previous to the last one verified). To fix this scenario we needed to delete that proof from state.proof table and regenerate it.
To correctly fix this issue we need to ensure that generating_since field is kept to a date (not null) until the tx that is sending the proof to be verfiied in L1 is confirmed. After the L1 tx is confirmed we can set the field to null or delete directly the proof from the state.proof table
Now when sending a final proof to L1 we are setting the generating_since field of this proof to null before the L1 tx is confirmed (while waiting for this confirmation), this can cause an edge scenario where that proof can be "reused" by a prover to aggregate it to an existing aggregation. When this happened an "invalid" aggregation proof is created, since this proof contains a proof (batches) that are already verified, therefore, the aggregator never consider this proof as final to send it to L1 (since it starts from a batch previous to the last one verified). To fix this scenario we needed to delete that proof from state.proof table and regenerate it.
To correctly fix this issue we need to ensure that generating_since field is kept to a date (not null) until the tx that is sending the proof to be verfiied in L1 is confirmed. After the L1 tx is confirmed we can set the field to null or delete directly the proof from the state.proof table