Some errors in updates of distributed entities attributes using PATCH methods

[ravaga]

I have 2 instances of Orion-LD, and I created 2 CSR in the Broker 1 pointing to Broker 2

{
    "type": "ContextSourceRegistration",
    "id": "urn:aeros:federation:Domain02:infrastructure",
    "information": [
        {
            "entities": [
                {
                    "type": "Domain"
                },
                {
                    "type": "LowLevelOrchestrator"
                },
                {
                    "type": "InfrastructureElement"
                }
            ]
        }
    ],
    "contextSourceInfo": [
        {
            "key": "Authorization",
            "value": "urn:ngsi-ld:request"
        }
    ],
    "mode": "inclusive",
    "operations": [
        "retrieveOps"
    ],
    "hostAlias": "Domain02",
    "management": {
        "localOnly": true
    },
    "endpoint": "192.168.1.25:1026",
    "status": "active",
    "aerosDomain": "Domain02",
    "aerosDomainFederation": true,
    "origin": "cache"
}

{
    "type": "ContextSourceRegistration",
    "id": "urn:aeros:federation:Domain02:services",
    "information": [
        {
            "entities": [
                {
                    "type": "Service"
                },
                {
                    "type": "ServiceComponent"
                },
                {
                    "type": "NetworkPort"
                },
                {
                    "type": "InfrastructureElementRequirements"
                }
            ]
        }
    ],
    "contextSourceInfo": [
        {
            "key": "Authorization",
            "value": "urn:ngsi-ld:request"
        }
    ],
    "mode": "inclusive",
    "operations": [
        "retrieveOps",
        "updateOps",
        "deleteEntity"
    ],
    "hostAlias": "Domain02",
    "management": {
        "localOnly": true
    },
    "endpoint": "192.168.1.25:1026",
    "status": "active",
    "aerosDomain": "Domain02",
    "aerosDomainFederation": true,
    "origin": "cache"
}

According to the defined operations, when I send a HTTP PATCH to /entities/urn:ngsi-ld:Domain:2 or /entities/urn:ngsi-ld:Domain:2/attrs/name to update the name attribute, it shouldn't be updated as only retrieveOps is configured. However, the entity is updated.

Taking a closer look to the logs, it seems that the "urn:aeros:federation:Domain02:services registration, which includes the updateOps operation, is matched.

However, if I send a GET /entities?type=Domain, the proper registration is matched

[ravaga]

Update: if the type is added to the queries (?type=Domain), it works as expected because no registration is matched because of the entity type (urn:aeros:federation:Domain02:services) or the operations (urn:aeros:federation:Domain02:infrastructure). It can be checked in the attached logs.

However, a 204 code is returned instead of an error code although the update operation is not allowed, no registration is matched and the entity doesn't exist locally. Therefore, which error code should return the broker?

• 400: bad request as the operation is not allowed in the registration matching the entity type
• 404: entity not found in the local broker as any registration is matched

[kzangeli]

This is a little but tricky but I believe a 404 should be returned.
I will have a look at it.

[ravaga]

The same happens for DELETE /entities/urn:ngsi-ld:Domain:2: the entity is deleted if the entity type isn't added to the query. However, when adding the entity type, a 404 is returned, so the same should be returned for the PATCH requests.

For DELETE /entities/urn:ngsi-ld:Domain:2/attrs/name, the attribute isn't removed because the deleteAttrs operation isn't included in any registration, so it's working as expected.

[kzangeli]

Yeah, if the broker has no knowledge of the type ...
Think I found an "easy" fix to the problem.

The registration must still be a match, as there is no info on the entity type of the entity to be patched/deleted.
But, if I add the entity type to the forwarded request, the second broker can decide to do nothing if the entity type is a non-match.
That should solve the problem.