We are building a POC using Corda 4 and Springboot web server.
The POC is running in dev mode in our local network.
The CorDapp developed for POC has four nodes -
Provider Node
Consumer 1 Node
Consumer 2 Node
Notary Node
There are three states-
State 1: NEW
State 2: APPROVED
State 3: CANCELLED
Every deal that takes place between the three nodes have three flows. Following are the three flows and the states:
Flow 1:
Provider Node --> Consumer 1 Node
Change State : NEW
Flow 2:
Consumer 1 Node --> Consumer 2 Node and Provider Node
Change State : NEW --> APPROVED
Flow 3:
Consumer 2 Node -- > Consumer 1 Node and Provider Node
State : APPROVED ---> CANCELLED
Many flows have been initiated in the CorDapp and most of them are in "APPROVED" state.
Due to new requirement, we had to change the flow definitions minutely. After changing, we created the updated CorDapp version and distributed to the four nodes.
After starting the nodes and CorDapp application, we found that the flows that are in "APPROVED" state cannot be started to change the state to "CANCELLED".
The flows are throwing error -
"The Initiator of CollectSignaturesFlow must pass in exactly the sessions required to sign the transaction."
Please note that the we are using all the correct sessions.
Question: How to update the Cordapp and continue old flows till "CANCELLED" state from "APPROVED"?
You didn't specify what the change was but my understanding is that if you change your states you have to run a schema migration. That is most likely the reason you're having this issue.
When in devmode you can pretty much just add the runSchemaMigration=true to your node config.
See example here: https://github.com/corda/cordapp-template-java/blob/release-V4/build.gradle#L103
Here's another resource that might be useful for that :https://www.corda.net/blog/upgrade-to-corda-os-46the-database-migration/
Related
We are building a POC using Corda 4 and Springboot web server.
The POC is running in DEV MODE in our local network.
The CorDapp developed for POC has four nodes -
Provider Node
Consumer 1 Node
Consumer 2 Node
Notary Node
Every deal that takes place between the three nodes have three flows. Following are the three flows and the states:
Flow 1: Provider Node --> Consumer 1 Node
Flow 2: Consumer 1 Node --> Consumer 2 Node and Provider Node
Flow 3: Consumer 2 Node -- > Consumer 1 Node and Provider Node
I executed first two flows on July 7, 2021 -
Flow 1 from "Provider Node" to "Consumer 1 Node" and
Flow 2 from "Consumer 1 Node" to "Consumer 2 Node" and Provider Node".
Both flows were successful
I stopped the nodes after the Flow 2.
Next day, on July 8, 2021, I restarted the nodes.
I initiated Flow 3 from "Consumer 2 Node" to "Consumer 1 Node and Provider Node".
It failed
Error thrown: "The Initiator of CollectSignaturesFlow must pass in exactly the sessions required to sign the transaction."
I then initiated Flow 1 for "Provider Node" to "Consumer 1 Node"
It failed too
Error thrown: "Don't know about OU=Bank, O=MyBank, L=Houston, C=U"
Question:
What could be the reason for the above?
Should I redeploy the nodes every time after the nodes are stopped?
Since you are using a PostgreqSQL database, when you do a clean deploy, the clean command doesn't clean the postgres database, unlike h2 database.
Ideally, in production system, it is expected that you will deploy your cordapp once, later of course you can upgrade your contract, states and flows when required but you will never clean off completely the database completely.
So right now what is happening is when you deploy your cordapp for the first time, certificates are generated by the bootstrapper tool(you can find these in build/nodes/PartyA/certificates folder), they are also saved in the DB. NodeInfos are also saved here build/nodes/PartyA/
When you do a clean build, the build folder is cleaned but the database is not cleaned and gets corrupted with the new entries which also has the new entries, and the node is confused with which entry to use.
So the solution is to drop and recreate the schemas in the database as well when you do a clean deploy at the node.
your flow seems to have a mismatch between the required signers for the transactions and the required participants in the state when trying to finalize the transaction.
not sure what you mean by 'redeploy' the nodes but you don't have to restart them every time. You shouldn't have to redeploy or restart them at all ideally.
thanks and good luck!
I found that by regenerating the node infos again before restarting the nodes, I was able to execute all the flows even after stopping and starting the nodes.
Commands used for regenerating the node infos :
java -jar corda.jar clear-network-cache
java -jar corda.jar generate-node-info
These commands were run from the "/build/nodes/" folder of each node.
I need to check how the notary prevents the double spending in the Obligation Cordapp. I started the web server UI at the localhost ports and performed some multiple transactions and when I checked the notary's log ,I found this:
[WARN ] 2020-06-24T08:29:33,484Z [Notary request queue processor] transactions.PersistentUniquenessProvider. - Unable to notarise: One or more input states or referenced states have already been used as input states in other transactions. Conflicting state count: 1, consumption details:
7CF1BCA8EDF25F0602BBEDF8AD41FD60336F65EAC09C5326478A4CB7CD620579(0) -> StateConsumptionDetails(hashOfTransactionId=46552C5CE153712B65585A75C4D165CD4A05304564C8797ACEF317DCD925B72E, type=INPUT_STATE).
To find out if any of the conflicting transactions have been generated by this node you can use the hashLookup Corda shell command. [errorCode=1g4005y, moreInformationAt=https://errors.corda.net/OS/4.5-RC02/1g4005y]
net.corda.core.internal.notary.NotaryInternalException: Unable to notarise: One or more input states or referenced states have already been used as input states in other transactions. Conflicting state count: 1, consumption details:
7CF1BCA8EDF25F0602BBEDF8AD41FD60336F65EAC09C5326478A4CB7CD620579(0) -> StateConsumptionDetails(hashOfTransactionId=46552C5CE153712B65585A75C4D165CD4A05304564C8797ACEF317DCD925B72E, type=INPUT_STATE).
To find out if any of the conflicting transactions have been generated by this node you can use the hashLookup Corda shell command.
I performed hashLookup on the invalid txId and found this :
hashLookup 46552C5CE153712B65585A75C4D165CD4A05304564C8797ACEF317DCD925B72E
Found a matching transaction with Id: A86E3ECE4EC12A487E413E2BDAB9D88BFEBCB418FA0224189DE0C72BBBD34B12
I believe this is how notary has stopped the double spending. But I am unable to recreate that testing.Can someone tell me what possible input transaction has led to this error.I mean what test case can lead to this testing of double spend that is stopped by notary?
A notary is a network service that provides uniqueness consensus by attesting that, for a given transaction, it has not already signed other transactions that consumes any of the proposed transaction’s input states.
In other words, the notary will keep track of all the input states (only stores their hashes, not the real state) that are used in transactions, so when someone is trying to use these already-spent inputs, the notary will reject the transaction.
Hence, preventing the double spend.
I performed below steps .
I have changed corda flow and removed this line , builder.setTimeWindow(serviceHub.clock.instant(), 30.seconds)
Now performed "gradle jar" command to build only jar and because of that created new corda app jar . e.g. old version "abc-1.1.jar" to new version "abc-1.2.jar"
Now I deployed new "abc-1.2.jar" in cordapps folder for node and restarted the node.
I am UNABLE to update old corda transactions and any update action on corda transaciton results into below error and corda node gets down after some time.
[INFO ] 2019-07-11T17:56:43,227Z [pool-12-thread-1] statemachine.FlowMonitor. -
Flow with id 90613d6f-be78-41bd-98e1-33a756c28808 has been waiting for 97904 seconds to receive messages from parties [O=BigCorporation, L=New York, C=US].
I am getting this issue and after 5 mins corda nodes stops saying heap space issue although i have given 6gb for norda node.
Please help to resolve this issue.
I am assuming that your flow is a pair of Initiator and Responder where the Responder runs on a different node. You might have updated the jar on the first node, but forgot to update it on the responder node so when your initiator is opening a FlowSession with the responder; the responder doesn't have the class for the Responding flow and Initiator is getting stuck waiting for a response. Check the logs (inside cordapps/log) of your responding node.
While upgrading from Corda 3 to Corda 4, I have an issue commiting a State to our node's ledger with only one Party. A single Party is able to create a state, notarize it, but CANNOT commit to the Corda 4 ledger without asking for an external third party.
The error Corda 4 produces (which Corda 3 did not produce) is the following:
(1) java.lang.IllegalArgumentException: A flow session for each external participant to the transaction must be provided. If you wish to continue using this insecure API then specify a target platform version of less than 4 for your CorDapp.
More specific context: Using FinalityFlow without a session yields a 'session required for external parties' error and does not complete. Adding only a session (e.g. session = initiateFlow(PartyA) ) results in an error that 'local nodes should not be included.'
Is there a workaround regarding this solution? It's important (for our use case) that a single Party can create a State and modify the State information without the involvement of other parties. Other use cases (where multiple parties are included) stem from this use case. Any guidance is greatly appreciated.
I think the error message is pretty spot on here. Just change the way you call FinalityFlow during your issuance such that it doesn’t contain a flow session to itself i.e.
return subFlow(new FinalityFlow(signedTransaction));
Although you may get a deprecation warning, in which case, do the following
return subFlow(FinalityFlow(stx, emptyList()))
need to implement corda node which is pure observer means which persist states but wont participate with other nodes for any transaction.
In order to acheive it i did followning thing:
Made 3 nodes as follow:
PartyA - Nodes contain cordApp jar including transactional flow, observerflow and Contract and states
PartyB - Nodes contain cordApp jar including transactional flow, observerflow and Contract and states
Observer - Nodes contain contract and State along with observer flow only.
On observer node all transactional nodes removed intentionally so that observer wont able to transact with other node.
After nodes start up, performed transaction from PartyA to PartyB by keeping Observer node as observer. It works perfectly.
Now i tried same thing from PartyA to observer and keep PartyB as observer. I expected transaction will get failed but transaction got committed on observer node even though observer node has no transactional flows.
When i tried to perform transaction from observer to PartyA then it gives error as no flow found which is expected.
Example i am using have ownable state and simple initiating flows are used.
My question is how one directional transaction worked with observer inspite of no flows on observer.
How can i prevent observer from not doing any transaction with other nodes, just act as pure observer.
As of Corda 3, the node actually installs default flow responders when it starts up for the four following flows:
FinalityFlow
NotaryChangeFlow
ContractUpgradeFlow.Initiate
SwapIdentitiesFlow
This is done in AbstractNode.installCoreFlows:
private fun installCoreFlows() {
installCoreFlow(FinalityFlow::class, ::FinalityHandler)
installCoreFlow(NotaryChangeFlow::class, ::NotaryChangeHandler)
installCoreFlow(ContractUpgradeFlow.Initiate::class, ::ContractUpgradeHandler)
installCoreFlow(SwapIdentitiesFlow::class, ::SwapIdentitiesHandler)
}
Thus the observer node will still be able to receive and record transactions as part of calls to FinalityFlow.
In a future version of Corda, this default FinalityFlow handler will be removed. Nodes will have to explicitly create a flow that receives and stores a transaction, allowing you to implement the behaviour above.