Unexpected behavior with HTTP loader when target key does not match target name

[kuczwara]

Using the HTTP target discovery feature, I noticed that target removals fail to be handled, with gnmic logging error messages showing the delete request failed with 404 error:

10.253.2.247 - - [05/Mar/2025:18:09:47 +0000] "DELETE /api/v1/config/targets/3 HTTP/1.1" 404 43
2025/03/05 18:09:47.929296 [gnmic] received response code=404, for DELETE http://10.253.2.247:7890/api/v1/config/targets/3

The JSON returned by the HTTP loader is similar to the following:

{
  "3": {
    "name": "router-name",
    "address": "192.168.100.1:57400",
    "username": "username",
    "password": "password",
    "token": null,
    "timeout": null,
    "insecure": true,
    "tls-ca": null,
    "tls-cert": null,
    "tls-key": null,
    "tls-max-version": null,
    "tls-min-version": null,
    "tls-version": null,
    "log-tls-secret": null,
    "skip-verify": true,
    "tls-server-name": null,
    "subscriptions": [
      "xxx"
    ],
    "outputs": [
      "yyy"
    ],
    "buffer-size": null,
    "retry": null,
    "tags": null,
    "event-tags": null,
    "proto-files": null,
    "proto-dirs": null,
    "gzip": null,
    "proxy": null
  }
}

The problem looks to be related to a mismatch between the target key and the target name in the JSON response. Judging from the logged error messages, when the target is removed from the JSON body and gNMIc polls the endpoint, gNMIc is attempting to delete the target using the name "3" instead of the assigned name "router-name". The rest of gNMIc appears to be using the assigned name "router-name", so this appears to be an inconsistency with the HTTP loading code.

Fixing the JSON keys to be equal to the name fixes this for me, but I'm wondering if the code should be fixed or documentation updated to be clear that keys in the JSON file for the HTTP loader are significant.

I checked the behavior in release 0.34.3 and with the latest build from the main branch.

[karimra]

That HTTP request looks like it's coming from another gNMIc instance, are you running a cluster ?

[kuczwara]

Yes, gNMIc is running with clustering enabled. In my test example, there was only one gNMIc instance in the cluster.