Summary
It looks like a transaction's upgrade_priority may be lost when the transaction is removed from the mempool and then stored in merge_input_cache.
In the conflict-replacement path, self.remove(conflicting_txid) is called before reading the priority from self.upgrade_priorities.
However, remove() also removes the corresponding entry from upgrade_priorities.
As a result, the cached transaction may receive the default priority instead of its original priority.
Possible impact
If a locally relevant transaction was inserted with UpgradePriority::Critical and then replaced by a merged transaction, the original transaction may be stored in merge_input_cache with Irrelevant priority.
If that transaction is later restored from the cache, the node may no longer treat it as financially relevant for proof or mutator-set updates.
Suggested fix
Read and store the conflicting transaction's priority before calling remove(), then use the stored value when inserting the transaction into merge_input_cache.
Suggested regression test
A regression test could verify that:
- A transaction enters the mempool with
UpgradePriority::Critical.
- A higher-fee merged transaction replaces it.
- The original transaction is stored in
merge_input_cache.
- When restored from the cache, its priority is still
Critical.
Please let me know if this behavior is intentional or if a small patch and regression test would be useful.
Summary
It looks like a transaction's
upgrade_prioritymay be lost when the transaction is removed from the mempool and then stored inmerge_input_cache.In the conflict-replacement path,
self.remove(conflicting_txid)is called before reading the priority fromself.upgrade_priorities.However,
remove()also removes the corresponding entry fromupgrade_priorities.As a result, the cached transaction may receive the default priority instead of its original priority.
Possible impact
If a locally relevant transaction was inserted with
UpgradePriority::Criticaland then replaced by a merged transaction, the original transaction may be stored inmerge_input_cachewithIrrelevantpriority.If that transaction is later restored from the cache, the node may no longer treat it as financially relevant for proof or mutator-set updates.
Suggested fix
Read and store the conflicting transaction's priority before calling
remove(), then use the stored value when inserting the transaction intomerge_input_cache.Suggested regression test
A regression test could verify that:
UpgradePriority::Critical.merge_input_cache.Critical.Please let me know if this behavior is intentional or if a small patch and regression test would be useful.