Misleading 404 response when updating map entries using the ID.

[jmdelafe]

Data Plane API supports updating a map entry using the ID but it returns a misleading 404 when doing it.

1. Before

$ echo "show map maps/paths.map" | socat stdio /tmp/admin.sock
0x103ea97b0 api apiservers
0x103ea9810 cart cartservers

2. Running the update for entry 0x103ea97b0. Notice the 404 Not Found.

$ curl -v --request PUT \
  --url 'http://127.0.0.1:5555/v3/services/haproxy/runtime/maps/paths.map/entries/%230x103ea97b0' \
  --header 'authorization: Basic YWRtaW46YWRtaW4=' \
  --header 'content-type: application/json' \
  --data '{
  "value": "newapiservers"
}'
*   Trying 127.0.0.1:5555...
* Connected to 127.0.0.1 (127.0.0.1) port 5555
> PUT /v3/services/haproxy/runtime/maps/paths.map/entries/%230x103ea97b0 HTTP/1.1
> Host: 127.0.0.1:5555
> User-Agent: curl/8.7.1
> Accept: */*
> authorization: Basic YWRtaW46YWRtaW4=
> content-type: application/json
> Content-Length: 30
>
* upload completely sent off: 30 bytes
< HTTP/1.1 404 Not Found
< Configuration-Version: 1
< Content-Type: application/json
< Vary: Origin
< Date: Fri, 19 Dec 2025 17:17:24 GMT
< Content-Length: 0
<
* Connection #0 to host 127.0.0.1 left intact

3. After. Notice the expected value for the 0x103ea97b0 entry

$ echo "show map maps/paths.map" | socat stdio /tmp/admin.sock
0x103ea97b0 api newapiservers
0x103ea9810 cart cartservers

The 404 is misleading since the entry is actually updated and will make operations like the sync with storage to never happen.

See #398 for more info regarding the environment used for testing.

[jmdelafe]

Similar to #398 (comment), the issue is when getting the entry after the update operation. It doesn't allow to use the ID.

In my testing, this applies for both "literal" and "regex" map files.