fix: minted early tracking #11066
fix: minted early tracking #11066
Conversation
- ensure multiples of the same NFA+amount are tracked
| @@ -174,8 +175,8 @@ export const prepareSettler = ( | |||
| intermediateRecipient: config.intermediateRecipient, | |||
| /** @type {HostInterface<TargetRegistration>|undefined} */ | |||
| registration: undefined, | |||
| /** @type {SetStore<ReturnType<typeof makeMintedEarlyKey>>} */ | |||
| mintedEarly: zone.detached().setStore('mintedEarly'), | |||
| /** @type {MapStore<ReturnType<typeof makeMintedEarlyKey>, bigint>} */ | |||
There was a problem hiding this comment.
What we really want is a MultiSet. Endo Patterns has CopyBag for that. I'm looking into whether we have a durable option.
There was a problem hiding this comment.
Cool didn't know that was option. Will look out for your reply on what to use here.
| @@ -221,7 +222,7 @@ export const prepareSettler = ( | |||
|
|
|||
| case PendingTxStatus.Advancing: | |||
| log('⚠️ tap: minted while advancing', nfa, amount); | |||
| this.state.mintedEarly.add(makeMintedEarlyKey(nfa, amount)); | |||
| self.queueMintedEarly(nfa, amount); | |||
There was a problem hiding this comment.
it's not really a queuing operation because there's no distinguishing the items. I think it should still be add. But ideally we don't need this separate method because the data store is a multiset that manages repeated items itself.
| @@ -256,7 +257,12 @@ export const prepareSettler = ( | |||
| const { value: fullValue } = fullAmount; | |||
| const key = makeMintedEarlyKey(forwardingAddress, fullValue); | |||
| if (mintedEarly.has(key)) { | |||
| mintedEarly.delete(key); | |||
| const count = mintedEarly.get(key); | |||
There was a problem hiding this comment.
we should be using get and delete abstraction on the map to treat it as a multiset.
if we don't have a multiset durable store, we can have a utility that performs the multi-set on them.
Description
Ensures the
mintedEarlystore can track multiple settlements for the same amount from the same address.Security Considerations
Ensures state diagram invariants are upheld.
Scaling Considerations
Same considerations as #10729 - the mapStore could grow large if an attacker spams the settlementAccount with uusdc. In these changes we ensure to delete map store entries when the count goes to 0.
Documentation Considerations
Changes should be clear to maintainers.
Testing Considerations
Adds a new test for the scenario not originally considered.
Upgrade Considerations
The
mintedEarlykind is a Remotable, so changing from aSetStoreto aMapStoredoes not seem to affect upgradability.These change should be included in the FUSDC GTM CE.