/V1/REGISTER-YOURSELF creates duplicate uuids when there is a change in the registry-office-application-release-number

[PrathibaJee]

There is a testcase in the testsuite which validates the configurability of the release number of the API /v1/register-yourself

ServiceLayer / BasicPart / /v1/register-yourself / Acceptance / Update LTP notified? / registry-office-application-release-number update With the input

{
  "registry-office-application": "RegistryOffice",
  "registry-office-application-release-number": "5.8.2",
  "registration-operation": "/v1/register-application",
  "registry-office-protocol": "HTTP",
  "registry-office-address": {
    "ip-address": {
      "ipv-4-address": "x.x.x.x"
    }
  },
  "registry-office-port": 3000
}

This results in changing the release-number of RO client from 2.0.1 to 5.8.2 (uuid : ro-2-0-1-http-c-ro-2-0-1-000)

ro-2-0-1-http-c-ro-2-0-1-000

```diff { + "uuid": "ro-2-0-1-http-c-ro-2-0-1-000", "ltp-direction": "core-model-1-4:TERMINATION_DIRECTION_SINK", "client-ltp": [ "ro-2-0-1-op-c-bm-ro-2-0-1-000", "ro-2-0-1-op-c-bm-ro-2-0-1-001", "ro-2-0-1-op-c-bm-ro-2-0-1-002", "ro-2-0-1-op-c-bm-ro-2-0-1-003", "ro-2-0-1-op-c-im-ro-2-0-1-000", "ro-2-0-1-op-c-im-ro-2-0-1-001", "ro-2-0-1-op-c-im-ro-2-0-1-002" ], "server-ltp": [ "ro-2-0-1-tcp-c-ro-2-0-1-000" ], "layer-protocol": [ { "local-id": "0", "layer-protocol-name": "http-client-interface-1-0:LAYER_PROTOCOL_NAME_TYPE_HTTP_LAYER", "http-client-interface-1-0:http-client-interface-pac": { "http-client-interface-configuration": { "application-name": "RegistryOffice", + "release-number": "5.8.2" } } } ] } ```

As a consequence of the /v1/register-yourself ,

• /v1/Register-application forwarding will be triggered for the own release-number 2.0.1(as per http-server)
• RO will create a new http-client for the release-number 2.0.1 with the uuid ro-2-0-1-http-c-ro-2-0-1-000

This results in duplicate uuid (ro-2-0-1-http-c-ro-2-0-1-000) for both the instances. Which creates the following problem , Ambiguity in reaching the right instance Validation error while retrieving control-construct because of duplicate entry

Practically this scenario is very rare. But , we shall modify the uuid creation logic to not create duplicate entry in any case.

[PrathibaJee]

Issue closed by mistake. Reopening it.

[PrathibaJee]

Setup : In RegistryOffice(RO) version 2.0.1, we have a RO client with release-number=2.0.1 (uuid : ro-2-0-1-http-c-ro-2-0-1-000 )

Steps :

1. Perform /v1/register-yourself with request-body/registry-office-application-release-number=random releaseNumber (let’s say 5.6.2)

   As a consequence , this will update the Registry-Office client’s release-number to 5.6.2 (for the uuid : ro-2-0-1-http-c-ro-2-0-1-000 )

2. A callback /v1/register-application will be initiated to as a forwarding for the /v1/register-yourself.

   The /v1/register-application request body will consists of the release-number=2.0.1 as per the http-server.

3. Since a client for 2.0.1 is not available in the configuration file , on receiving the /v1/register-application request, server will creat new LTPs (with uuid : ro-2-0-1-http-c-ro-2-0-1-000)

Problem : This results in two identical uuids and makes the application to behave inconsistent.

We don’t have a solid proposal for this problem now. But just a thought, Since we are not going to depict anything from the uuid, if server generates a uuid which is already existing , shall we tune the uuid without changing the basic pattern of the uuid? example : If ro-2-0-1-http-c-ro-2-0-1-000 already exist , then check ro-2-0-1-http-c-ro-2-0-1-001 already exist , then check ro-2-0-1-http-c-ro-2-0-1-002 exist…