Allow the Issuer to Record Token States

[mplatt]

It appears to be impossible to record a FungibleToken inside the issuers vault during issuance or redemption.
This appears to be due to the role selection mechanism in ObserverAwareFinalityFlow.

That means that, even if I pass the issuer as observer on issuance, no state will be recorded in their vault:

@Test
fun `issuer can observe issuance`() {
	val token = 7.GBP issuedBy nodeA.legalIdentity() heldBy nodeB.legalIdentity()
	nodeA.startFlow(IssueTokens(listOf(token), listOf(nodeA.legalIdentity())))
	network.runNetwork()
	val criteria = QueryCriteria.VaultQueryCriteria(
		status = Vault.StateStatus.ALL,
		relevancyStatus = Vault.RelevancyStatus.ALL
	)
	assertThat(nodeB.services.vaultService.queryBy<FungibleToken>(criteria).states, hasSize(equalTo(1)))
	assertThat(nodeA.services.vaultService.queryBy<FungibleToken>(criteria).states, hasSize(equalTo(1))) // FAILS
}

Similarly, on redemption:

@Test
fun `issuer can observe redemption`() {
	val token = 7.GBP issuedBy nodeA.legalIdentity() heldBy nodeB.legalIdentity()
	nodeA.startFlow(IssueTokens(listOf(token), listOf(nodeA.legalIdentity())))
	network.runNetwork()
	nodeB.startFlow(RedeemFungibleTokens(1.GBP, nodeA.legalIdentity(), listOf(nodeA.legalIdentity())))
	network.runNetwork()
	val criteria = QueryCriteria.VaultQueryCriteria(
		status = Vault.StateStatus.ALL,
		relevancyStatus = Vault.RelevancyStatus.ALL
	)
	assertThat(nodeB.services.vaultService.queryBy<FungibleToken>(criteria).states, hasSize(equalTo(2)))
	assertThat(nodeA.services.vaultService.queryBy<FungibleToken>(criteria).states, hasSize(equalTo(2))) // FAILS
}

[arsalankhalid]

Is this ever going to be addressed?

[rach-id]

I had this same issue lately :(
The way I solved it is via sharing the transaction with the issuer and asking it to record all visible states (via a responder):

• On the node starting the flow:

 if (!serviceHub.myInfo.isLegalIdentity(issuerParty))
         subFlow(FinalityFlow(signedTx, listOf(session), StatesToRecord.ALL_VISIBLE))

• On the issuing node:

subFlow(ReceiveFinalityFlow(otherSideSession = flowSession, statesToRecord = StatesToRecord.ALL_VISIBLE))

Then, to get the balance, you should query ALL states instead of RELEVANT ones.

[manosbatsis]

Is this the right way for parties to keep tabs on tokens they have issued though? Seems like additional room for a junior/careless dev to mess up in some way or other with e.g. token selection.

Never saw a need for someting like this tbh, always used separate, custom states to support processes resulting in issuance/transfer/redemption, easier to work with in most cases. Curious about what requirements might have a real need for this.

[rach-id]

Agreed, it is hacky :D
What do you mean by custom states to support processes resulting in issuance/transfer/redemption? Keeping track of the results in states you manage manually ? and share them if some other party needs to know ?

[manosbatsis]

E.g. an IssueRequestState used to accommodate interactivity/negotiations between parties around an issuance request/offer.

[rach-id]

Wouldn't that be redoing a part of what the tokens SDK is doing ? Since they already handle parts of keeping the issuance stored and others...

[manosbatsis]

Custom transaction items support the functional scope. A purchase order provides more context that a couple of balance updates. This is one of the reasons the SDK is layered in flows, inline flows and TX item adding functions - it's about what some definition of "atomic" TX is supposed to include.

[rach-id]

Sorry for the late reply.
Makes sense this way. Agreed. Thanks a lot for the insights