Resolving StatePointers Is Not Optional

[opticyclic]

According to the docs

Resolving state pointers in TransactionBuilder

When building transactions, any StatePointers contained within inputs or outputs added to a TransactionBuilder can be optionally resolved to reference states using the resolveStatePointers method. The effect is that the pointed to data is carried along with the transaction. ### This may or may not be appropriate in all circumstances, which is why calling the method is optional.

There is no parameter to prevent the pointed to data being carried along with the transaction and it always get carried across whether you want it to or not.

[opticyclic]

See this repo
https://github.com/opticyclic/corda-linearpointer-demo

and specifically this test to demonstrate the problem
https://github.com/opticyclic/corda-linearpointer-demo/blob/master/workflows/src/test/kotlin/com/github/opticyclic/corda/demo/linearpointers/flows/EndToEndTest.kt

[MrMatthewLayton]

@opticyclic As of Corda 4.3 there is a parameter called isResolved to prevent pointed-to data being pulled into the transaction as a reference state:

Note the API for Corda 4.0 when state pointers were introduced:
https://api.corda.net/api/corda-os/4.0/html/api/kotlin/corda/net.corda.core.contracts/-state-pointer/index.html

And here in 4.3 where isResolved was introduced:
https://api.corda.net/api/corda-os/4.3/html/api/kotlin/corda/net.corda.core.contracts/-state-pointer/index.html

It was me who introduced that change after discussing with @roger3cev as it was causing a bug with StaticPointers.

[nargas-ritu]

@opticyclic Does the above answer your question?

[opticyclic]

You can rebuild the test above with 4.9 to verify.