[Version-unspecific] TxOutStoreItem RetrievalKey field for not needing to rederive key-value pair key for overwrite/deletion
[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 Set
s 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.