CORE-9031: Add forceUpgrade parameter to VirtualNodeUpgradeRequest #1263
Conversation
Tom-Fitzpatrick
force-pushed
the
tomf/CORE-9031/vnode-force-operation-in-progress
branch
from
919e50d to
444c0dc
Compare
|
Jenkins build for PR 1263 build 11 Build Successful: |
Tom-Fitzpatrick
force-pushed
the
tomf/CORE-9031/vnode-force-operation-in-progress
branch
2 times, most recently
from
18f0a00 to
e47e1d4
Compare
gradle.properties
Outdated
| @@ -9,7 +9,7 @@ cordaProductVersion = 5.1.0 | |||
| # NOTE: update this each time this module contains a breaking change | |||
| ## NOTE: currently this is a top level revision, so all API versions will line up, but this could be moved to | |||
| ## a per module property in which case module versions can change independently. | |||
| cordaApiRevision = 26 | |||
| cordaApiRevision = 27 | |||
There was a problem hiding this comment.
Is it a breaking change though?
I wonder if Avro will do defaulting for us automatically if the recipient has a new schema and payload does not have the value for the field?
FAO: @simon-johnson-r3
There was a problem hiding this comment.
I tried without the version bump, to see if I could get a green build in runtime-os without it. But the corda-api PR build here fails first because it tests the PR with corda-runtime-os code. The generated java file for VirtualNodeUpgradeRequest doesn't provide a constructor without forceUpgrade, and we get the following error when trying to use it:
e: file:///var/jenkins/workspace/ion-compatibility_release_os_5.1/components/virtual-node/virtual-node-rest-service-impl/src/main/kotlin/net/corda/virtualnode/rest/impl/v1/VirtualNodeRestResourceImpl.kt:348:41 None of the following functions can be called with the arguments supplied: public constructor VirtualNodeUpgradeRequest() defined in net.corda.data.virtualnode.VirtualNodeUpgradeRequest | public constructor VirtualNodeUpgradeRequest(virtualNodeShortHash: String!, cpiFileChecksum: String!, actor: String!, forceUpgrade: Boolean!) defined in net.corda.data.virtualnode.VirtualNodeUpgradeRequest
I don't think there's a good way around this, so I think the version bump is necessary.
There was a problem hiding this comment.
Yes, I agree - looks like we will not be able o workaround without version bump.
Signed-off-by: TomFitzpatrick <[email protected]>
Signed-off-by: TomFitzpatrick <[email protected]>
Signed-off-by: TomFitzpatrick <[email protected]>
Signed-off-by: TomFitzpatrick <[email protected]>
Signed-off-by: TomFitzpatrick <[email protected]>
Signed-off-by: TomFitzpatrick <[email protected]>
Signed-off-by: TomFitzpatrick <[email protected]>
Tom-Fitzpatrick
dismissed stale reviews from josephzunigadaly and vkolomeyko
via
a11bb9b
Tom-Fitzpatrick
force-pushed
the
tomf/CORE-9031/vnode-force-operation-in-progress
branch
from
743a8fb to
a11bb9b
Compare
Tom-Fitzpatrick
deleted the
tomf/CORE-9031/vnode-force-operation-in-progress
branch
This adds an optional forceUpgrade field to the VirtualNodeUpgradeRequest schema which defaults to false. This supports the work being done in corda/corda-runtime-os#4734.