RO application server is getting terminated during software upgrade process.

[vanithavalluripalli9]

Problem Description:

When we do software upgrade process then during execution of callbacks RO server is getting terminated with the below mentioned error.

onf-core-model-ap\applicationPattern\onfModel\models\layerProtocols\HttpClientInterface.js:79
let layerProtocol = logicalTerminationPoint[
^

TypeError: Cannot read properties of undefined (reading 'layer-protocol')
at Function.getApplicationNameAsync (RegistryOffice-develop\server\node_modules\onf-core-model-ap\applicationPattern\onfModel\models\layerProtocols\HttpClientInterface.js:79:52)
at async RegistryOffice-develop\server\node_modules\onf-core-model-ap\applicationPattern\rest\client\eventDispatcher.js:39:41

Note : Issue is inconsistently seen in ALT as well

Priority:Low;
AffectedFlow:Software Upgrade/RO:bequeath-your-data-and-die;

[DanaSunal]

I am not able to reproduce the issue. I assume request for bequeath-your-data-and-die is sent to RO. Could you be more specific about what kind of request is sent? headers, request body, etc. The error mentioned is a consequence.

[vanithavalluripalli9]

I apologize for the poor description. Please find the detailed scenario where issue is reproducible :

When we execute /v1/bequeath-your-data-and-die in EaTL then during series of callbacks sent to RO this issue is reproducible.

[DanaSunal]

Thank you, but I am still unable to reproduce it. All callbacks from EATLs bequeath-your-data-and-die come back with 204 and Registry Office is still alive.
Can you provide request body?

[vanithavalluripalli9]

Please find the below mentioned scenario :

We have to maintain 2 versions of EATL .
Current version : EATL 2.0.1
New version : EATL 2.0.2

Register EATL 2.0.2 at RO by executing register-yourself in EATL 2.0.2 with below mentioned request body :

{
"registry-office-application": "RegistryOffice",
"registry-office-application-release-number": "2.0.1",
"registration-operation": "/v1/register-application",
"registry-office-protocol": "HTTP",
"registry-office-address": {
"ip-address": {
"ipv-4-address": "1.1.3.8"(address where RO deployed)
}
},
"registry-office-port": 3008,(port where RO deployed)
"http-address": {
"ip-address": {
"ipv-4-address": "1.1.3.9"(address where current server is deployed)
}
},
"http-port": 3009,(port where current server is deployed)
"preceding-application-name": "ExecutionAndTraceLog",
"preceding-release-number": "2.0.1"
}

Then approve EATL v2.0.2 by executing /v1/document-approval-status in TAR with below mentioned request body :
{
"application-name": "ExecutionAndTraceLog",
"release-number": "2.0.2",
"approval-status": "APPROVED"
}

This will automatically trigger /v1/bequeath-your-data-and-die in EATL 2.0.1 during embedding process after approval.
As part of the series of callbacks sent to RO mainly during callback promptForBequeathingDataCausesRequestForDeregisteringOfOldRelease we can notice the issue.

Note : Before executing the above requests make sure all the TAC applications are integrated with each other and able to communicate with each other.
Note : As this is inconsistent kindly try to execute 2-3 times .

[DanaSunal]

I think I can replicate it much easier (if it's the same problem, as I wrote, the error message is just a consequence, meaning multiple issues can result in this same error).

curl -X POST "http://localhost:3008/v1/deregister-application" -H "accept: application/json" -H "user: User Name" -H "originator: Resolver" -H "x-correlator: 550e8400-e29b-11d4-a716-446655440000" -H "trace-indicator: 1.3.1" -H "customer-journey: Unknown value" -H "operation-key: gfsg" -H "Content-Type: application/json" -d "{\"application-name\":\"ExecutionAndTraceLog\",\"release-number\":\"2.0.1\"}"

triggers this error and this time it is caused by dangling fc-port. We are deleting application data, but I can only see deletion of LTPs (http-c, tcp-c and op-c) but I cannot see any code dealing with removing the fc-ports from the config file.

( see ControlConstruct.deleteApplicationInformationAsync )

The error just then comes due to the code not being able to look for operation name, as the LTP is already deleted, but the fc-port with the logical-termination-point stayed.

@PrathibaJee @vanithavalluripalli9 am I reading this right, should the functionality be implemented?