Summary

Aptos mempool garbage collection should happen at beginning of transaction ingress loop. Currently, it happens at the end. As a result, if a single signer retries a failed transaction that should have expired, their first attempted retry will throw an error:

1. Send in a transaction with sequence number $n$ that gets submitted, but fails. Garbage collect at $t_1$ after submission.
2. Wait for expiration and try another transaction with sequencer number $n$.
3. Transaction gets rejected at mempool because previous attempt at sequence has not been garbage collection. Garbage collect at $t_2$.

There is some chance this can cascade outside of the core mempol itself. That is, above the third attempt to submit the transaction should once again succeed at mempool validation. However, it is possible there is some other part of our system which might hold onto the value at $t_1$ and therefore reject, e.g., the memseq mempool.