Issue: Boolean Values Interpreted as 1/0 in RTDS Configuration

[gordon-wang-lyft]

If you are reporting any crash or any potential security issue, do not
open an issue in this repo. Please report the issue via emailing
envoy-security@googlegroups.com where the issue will be triaged appropriately.

Title: Issue: Boolean Values Interpreted as 1/0 in RTDS Configuration

Description:

While working with the Envoy Runtime Discovery Service (RTDS), I encountered an issue where boolean values (bool_value:true/false) in the RTDS configuration are being interpreted as 1/0 instead of true/false when processed
by Envoy.

Repro steps:

1. Configure RTDS with a boolean value, e.g., (fields:{key:"envoy.features.http2_use_oghttp2" value:{bool_value:true}}).
2. Observe the processed configuration in Envoy, where the boolean is represented as 1 instead of true. See the following section for detailed output

Admin and Stats Output:

There is not specific admin output. While when query the 9901/runtime we do obtain the mis-interpreted value:

curl -s 0:9901/runtime | grep -A10 oghttp2
  "envoy.features.http2_use_oghttp2": {
   "final_value": 1,
   "layer_values": [
    "false",
    1,
    ""
   ]
  },

Config:

Envoy Version: this bug still exists after we upgraded Envoy to 1.30

Expected Behavior:

The boolean values in the RTDS configuration should be preserved as true/false when processed by Envoy.

Actual Behavior:
The boolean values are being converted to 1/0 in the final layer configuration seen by the Envoy sidecar.

Additional Context:

1. This issue could lead to unexpected behavior in features relying on boolean flags.
2. The problem seems to stem from how RTDS handles the protobuf message type for booleans, converting them to integers in the final config.

[milton0825]

@alyssawilk

[alyssawilk]

any chance you can dump an actual RTDS update? My guess is you're sending the value "true" in quotes at which point it'd be parsed as a string not a boolean

[milton0825]

@gordon-wang-lyft was able to reproduce this issue in a unit test and is working on a patch.

[gordon-wang-lyft]

Thanks, @alyssawilk! We are sending boolean true or false instead of string "true" and "false".

We performed a dump of an actual RTDS update with a boolean value and observed the same result. We identified the root cause:

• Envoy Core uses Abseil's absl::StrCat to convert booleans to "0" or "1" and stores them in entry.raw_string_value_.
• According to the Abseil documentation, this behavior is expected for boolean conversion.
• This aligns with the test outputs and debugging data we collected.

Regarding the suggestion to use "true" and "false" strings, our preference is to avoid this. Envoy's direction, as per issue #27434, is to pass correct data types directly instead of using strings for booleans and numbers. We’ve already adapted our implementation to pass in booleans directly, aligning with this approach.

Since true and false are initially loaded correctly as strings, onConfigUpdate should maintain that format rather than convert them to "0" and "1". I will create a PR to address this behavior and update the ticket accordingly.

[gordon-wang-lyft]

#36044

[github-actions]

This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged "help wanted" or "no stalebot" or other activity occurs. Thank you for your contributions.

[github-actions]

This issue has been automatically closed because it has not had activity in the last 37 days. If this issue is still valid, please ping a maintainer and ask them to label it as "help wanted" or "no stalebot". Thank you for your contributions.