Skip to content

[Version-unspecific] TxOutStoreItem RetrievalKey field for not needing to rederive key-value pair key for overwrite/deletion

Multipartite requested to merge Multi/modify-retrieved-TxOutStoreItem into develop

[Version-unspecific]

Intended to close #1843 (closed)
'Some old outbounds remain stuck in signer storage'
by ensuring that the TxOutStoreItem key-value pair retrieved by the iterator in List
is the same one which is then overwritten with Set or deleted with Remove,
rather it possible for a Key() behaviour change to duplicate or leave undeletable iteratable (SignerStore) key-value pairs.

processTransactions calls SignerStore OrderedLists
which calls SignerStore List
which iterates through the stored TxOutStoreItem key-value pairs;
processTransactions or signAndBroadcast (called by it)
then may call Set here or here to overwrite it (update it for Checkpoint/SignedTx)
or call Remove to delete it here.
|
What should not happen is that the code retrieves a TxOutStoreItem with the List iterator and then Sets an updated duplicate item with a different key without having removed the first,
or retries a TxOutStoreItem with the List iterator and then tries to Remove it with a different key and cannot Remove it, leaving the key-value pair undeleted in the SignerStore.

#1843 (closed) reports that failure to remove has indeed taken place (if I understand correctly) due to changed Key behaviour which seeks to rederive the key that the item retrieved by the iterator had (Key is also used to Set an item for the first time with a unique key);
however, since the iterator allows iterator.Key() in the same way as iterator.Value(), it appears possible to record the key at time of retrieval to ensure that that key-value pair is the same one either modified or deleted later, even should key-derivation code change.

It is my hope that this would both guard against any similar changes in future and also resolve the specific items currently stuck in the SignerStore.

If any TxOutStoreItem retrieved from the SignerStore is deliberately used as a template to make a second SignerStore item without deleting the first, this approach would require manually clearing the RetrievalKey field of the duplicate before its Set, but I am not currently aware of a reason why this would be done.

Merge request reports