As mentioned in the docs on performing flow upgrades, all you need to do is basically shut down the node, replace JAR, and start the node back up. When I do this, when my upgraded flow is run the next time, I get the following error:
net.corda.core.contracts.TransactionVerificationException$ContractConstraintRejection: Contract constraints failed for com.company.project.contract.MyContract, transaction: ABCDEFG
And the flow does not complete as a result. What am I doing wrong?
As my experience it seem like Corda flow upgrade not update network parameter (state still belong to old hash, old contract). Then when replace with new contract it will be contract constraint.
So I think you have 3 way to manage this
For local network bootstrap, update network parameter before doing flow upgrade (I use network-bootstrap.jar for copy new contract to cordapp folder, then it will append new contract hash immediately)
For Corda network, you must contact network operator for update new hash.
Use SignatureConstraint of Corda4 (they claim that it's upgrade easier but I didn't try yet)
Hope this help
Related
I have a requirement to find if there are any updates in Git Remote branch compared to the local branch cloned earlier. If there are any updates available, application must notify the user and on user consent, a pull request has to be performed in Java.
I tried using JGIT
org.eclipse.jgit.lib.BranchTrackingStatus.of(git.getRepository(), git.branchList().call().get(0).getName()).getBehindCount() to know if my local repository is behind the remote repository. This is always returning 0.
1st parameter to the function BranchTrackingStatus.of must be a Repository object, and the object passed is local repository object.
Appreciate any suggestions to tackle this scenario.
BranchTrackingStatus compares a local branch with the configured remote tracking branch, e.g. refs/heads/foo with refs/remotes/origin/foo (if the default naming convention is followed).
The method does not update the remote tracking branch. Unless you first fetch the branch in question from the remote repository, no change will be reported.
FetchResult result = git.fetch()
.setRemote("origin")
.setRefSpecs("refs/heads/foo:refs/remotes/origin/foo")
.call().
The result holds details of the succeeded operation or why it couldn't be completed.
Does that solve your problem?
New to Corda and I am trying to run (debug) flow tests using the Corda Accounts in a Mock Network and get the following error :
java.lang.IllegalArgumentException: Corda service com.r3.corda.lib.accounts.workflows.services.KeyManagementBackedAccountService does not exist
when trying to create a anew account, or anything else for that matter. Is there something I am missing ? Any code would be appreciated.
That service is under com.r3.corda.lib.accounts.workflows.services package, meaning it's part of the accounts-workflows CorDapp; so you must include that CorDapp in your mocked network so it gets installed on your mocked nodes:
// Setup network.
network = new MockNetwork(new MockNetworkParameters().withCordappsForAllNodes(ImmutableList.of(
TestCordapp.findCordapp("com.r3.corda.lib.tokens.contracts"),
TestCordapp.findCordapp("com.r3.corda.lib.tokens.workflows"),
TestCordapp.findCordapp("com.r3.corda.lib.tokens.money"),
TestCordapp.findCordapp("com.r3.corda.lib.tokens.selection"),
TestCordapp.findCordapp("com.r3.corda.lib.accounts.contracts"),
// This CorDapp has the missing service from your error message.
TestCordapp.findCordapp("com.r3.corda.lib.accounts.workflows"),
TestCordapp.findCordapp("com.r3.corda.lib.ci")))
In general, if your node is supposed to run some code, you must install that code on that node; otherwise how it will be able to run it? So if you're using some library (e.g Accounts library, Tokens SDK); then you must install it on your node.
I am going through this documentation and I have several uncertainties.
Performing explicit contract and state upgrades
Preserve the existing state and contract definitions
Write the new state and contract definitions
Create the new CorDapp JAR
Distribute the new CorDapp JAR
Stop the nodes
Re-run the network bootstrapper (only if you want to whitelist the
new contract)
Restart the nodes
Authorise the upgrade
Perform the upgrade
Migrate the new upgraded state to the Signature Constraint from the
zone constraint
Questions:
1. Preserve the existing state and contract definitions
2. Write the new state and contract definitions
3. Create the new CorDapp JAR
How do I do that? is it meant only to preserve jars with contracts and states on nodes, not preserving them in source code? If I do not preserve them in source code then how can I create the upgrade method?
interface UpgradedContract<in OldState : ContractState, out NewState : ContractState> : Contract {
val legacyContract: ContractClassName
fun upgrade(state: OldState): NewState
}
If I do not preserve old state in source code, then shoud I name the jar differently each time I need to do an upgrade?
Can old jars be reoved from the node when the upgrade was completed?
6. Re-run the network bootstrapper (only if you want to whitelist the
new contract)
8. Authorise the upgrade
Am I right that only those 2 steps are related to Explicit contact upgrades? And If I use implicit flow with signature, then I need to skip only those two steps, while the others are still aplicable and must be performed?
9. Perform the upgrade
Should this be done for each state separately by the owner of the state? In that case should I run it on each node for specific contrcats where the node is the participant of the state? (In doc it is mentioned to be run on single node - but what id=f a single node is not participant of some state)
Other questions
This section describes explicit contracts and states update.
https://docs.corda.net/upgrading-cordapps.html#performing-explicit-contract-and-state-upgrades while signature constraint section (https://docs.corda.net/api-contract-constraints.html#signature-constraints) does not describe an update process for states.
is it the same as for explicit upgrades with the difference only in steps 6,8 or it is somewhat completely different?
Do I need to create the function transforming old states to new states in that case? if not , then how the old states will be handled by new flows?
I see you have many some great questions about contract upgrades. Here is an article that is written by one of our dev-relation engineers. https://medium.com/corda/contract-upgrades-and-constraints-in-corda-425055a9a47f
Feel free to follow up any additional questions that you have.
If you are new to Corda, feel free to join the Corda community channels #http://slack.corda.net/
While performing legacy contract upgrades, you need both the old and new contract jars installed on your node. (present in the cordapps folder).
You can create a new Gradle module say v2-contract and write the new contract in this. This is where you will write your UpgradedContract. You will need to refer to the old v1-conract jar as well as it needs to know what the old state was. To do this add a gradle dependency in v2-contract like below.
dependencies {
// Corda dependencies.
cordapp project(v1_contract)
}
The old jar can be removed from the cordapps folder, once all the states have been upgraded to new v2-contract.
a. For HashConstraints there is no need to run the bootstrapper again. You will write the new contract by implementing UpgradedContractWithLegacyConstraint,run the jar task to build this new jar, add it to the cordapps folder, run the Authorise Flow from all nodes, run the Initiate flow from one of he node's terminal. This is the explicit way of upgrading.
b. However if you are using Whitelistzoneconstraint, you want to make sure to add the new v2-contract jar's hash to whitelist param in network param. You will need to run the network Bootstrapper to whitelist this new v2-contracts jar hash. https://docs.corda.net/network-bootstrapper.html#whitelisting-contracts.
Once you do that you can either go for an explicit upgrade by implementing UpgradedContract, or you can use implicit upgrade.
c. If you are using Signature Constraints, no need to run the network Bootstrapper for the new jar, write the new v2-contract, build it using gradle jar task, replace old jar with new jar. This is the implicit way of upgrading.
You should run the Authorise Flow for all the participants only.
Other questions
There is no explicit upgrade in Signature constraints. You need to make sure you write your state in a backward compatible way, build new jar, replace old jar with new jar. The states will refer to the new contract then.
Hope that helps. Feel free to post more questions on the above answer or ping on Slack.
Is corda support state deletion scenario when don't need to use some state (in both dev/prod)
Because I face exception when start node like "class not found exception", It's happen when I delete state class in project and use same old persistence file.
I think it because of state class already insert in VAULT_STATES and it can't find that class when start node.
I expect to have some method that provide state deletion.
More info
In Dev side I delete persistence file and of course it's work, but I just worry about Production side.
As of Corda 3, if a node has a state stored as part of a transaction in its transaction storage or in its vault, the node needs to keep the state's class definition on its classpath permanently.
You can delete old transactions and states directly via the node's database, but only if the transactions are not required for transaction resolution. You would do this by dropping rows from the NODE_TRANSACTIONS and VAULT_STATES tables in the node's database (as well as any custom tables defined by the state's schemas if it is a QueryableState). However, if the deleted transactions are later required as part of transaction resolution, your node will throw an error.
Future versions of Corda may provide a mechanism to delete old or "non-current" states and transactions. You can find a discussion of what this process may look like here: https://groups.io/g/corda-dev/topic/20405353.
For development purposes you can simply just delete the persistence.mv.db file which is the entire H2 database. This will reset your corda node.
Of course don't do that for any production use.
During vm creation in openstack, one can specify a keypair name, so that the specified public key get injected to the newly created vm.
I would like to know in which state of machine the key injection is done, completely? Given the machine is in ACTIVE state, does that guarantee that the key injection is completed?
Details:
I have a limited quota for the key pairs and I would like to delete each keypair from openstack immediately after they get injected to the target machine. I have only access to openstack ReST API and NOT to the target vm.
UPDATE
Looking at nova instances table, I can see that "key name" and "key data" are existing there too. I think the key is copied to this table and then the original key is not referenced any more. So deleting the key shouldn't cause any issue. am I wrong?
What you can do is try a ssh connection and once that succeeds, proceed to delete the keypair.
To answer your question directly, the key is added via the cloud-init. You can grep for ssh in /var/log/cloud-init.log to see when exactly it happens. (It happens pretty early in the cloud-init process).
I don't think there is any API way of figuring out when exactly the key injection happens. Machine in ACTIVE state is not a guarantee that cloud-init part of key injection is done (though for practical purposes, it does happen pretty early).
You could try checking it via nova console-log. Though the output of console-log has limited buffer, so it may overshoot the key addition part and hence you may not see it in console log.
So, I think checking via actual ssh connection is the only sure shot way.