fix: use TextFormat for message-valued CEL attributes (restore pre-1.37 behavior under Protobuf 30+) by zhaohuabing · Pull Request #43508 · envoyproxy/envoy

zhaohuabing · 2026-02-16T06:32:11Z

Commit Message:

Envoy 1.37.0 updated protobuf from 29.3 to 33.2. That dependency change altered debug-string output semantics and broke behavior that worked in 1.36.x for ext_proc consumers parsing xds.virtual_host_metadata.

This behavior change was introduced in #42435 and #42827.

This PR switches message serialization from debug-string APIs to protobuf text-format APIs so message-valued CEL attributes are machine-parseable again, as recommended by protobuf programming guides. https://protobuf.dev/programming-guides/deserialize-debug

What broke in 1.37.0

In both 1.36.x and 1.37.0, message-valued CEL results were stringified via ShortDebugString().
In 1.36.x (protobuf 29.3), that output was parseable.
In 1.37.0 (protobuf 33.2), debug strings are now prefixed with goo.gle/debugonly / goo.gle/debugstr, which is intentionally non-parseable as textproto.
Result: ext_proc implementations that parse xds.virtual_host_metadata as textproto started failing after upgrading to 1.37.0.

Note: xds metadata attributes in ext_proc requests are not diagnostic log fields; they are machine-to-machine payload data consumed by external processors. External processors parse these values to make policy and routing decisions, so serialization must be stable and machine-readable by standard protobuf tooling. DebugString is a diagnostic format with no compatibility contract, and in protobuf 30+ it may include goo.gle/debug... prefixes that intentionally break parsing. For this path, protobuf TextFormat is the correct format, not debug serialization.

Example

Given virtual host metadata:

  {
    "metadata": {
      "filterMetadata": {
        "envoy-gateway": {
          "resources": [
            {
              "kind": "Gateway",
              "name": "eg",
              "namespace": "default",
              "sectionName": "http"
            }
          ]
        }
      }
    }
  }

Before (1.37.0 + protobuf 30+ path), ext_proc may receive:

goo.gle/debugonly filter_metadata { key: "envoy-gateway" value { ... } }

Parsing fails at token 1.

After this PR:

filter_metadata { key: "envoy-gateway" value { ... } }

This is protobuf text format and parses via TextFormat::ParseFromString(...).

Compatibility notes

This restores 1.36.x-like effective behavior for ext_proc users (parseable metadata strings), while using the correct serialization API.
Minor formatting differences vs 1.36.x debug output are possible (whitespace/order), but output is now stable machine-readable textproto.
Scope includes other call sites using Expr::print(...) for message-valued CEL results (for example rate-limit descriptor CEL stringification).

Additional Description:
Risk Level: low
Testing: unit and integration test
Docs Changes:
Release Notes: yes
Platform Specific Features:
[Optional Runtime guard:]
[Optional Fixes #Issue]
[Optional Fixes commit #43466]
[Optional Deprecated:]
[Optional API Considerations:]

zhaohuabing · 2026-02-16T08:04:51Z

Could we cherry-pick this into v1.37.1?
It breaks existing ext proc filters for Envoy Gateway users.

wbpcode · 2026-02-18T02:23:49Z

Could we add a runtime guard with default value to true?
Although ideally this is unnecessary because the behavior has been broken by the deps upgrading. But anyway the broken behavior is part of released 1.37, it would be better add a guard, and it's simple and harmless

repokitteh-read-only · 2026-02-19T03:17:08Z

CC @envoyproxy/runtime-guard-changes: FYI only for changes made to (source/common/runtime/runtime_features.cc).

🐱

Caused by: #43508 was synchronize by zhaohuabing.

see: more, trace.

Signed-off-by: Huabing (Robin) Zhao <zhaohuabing@gmail.com>

wbpcode

LGTM. Thanks for this contribution.

yanjunxiang-google · 2026-02-23T22:37:39Z

Please fix CI errors. Otherwise LGTM

yanjunxiang-google · 2026-02-23T22:38:12Z

+    }
+    std::string textproto;
+    Protobuf::TextFormat::Printer printer;
+    printer.SetSingleLineMode(true);


Is SingleLineMode preferred here?

Yes, prefer SignleLineMode here because:

It keeps one line, avoids embedding \n into the values.

It also stays closer to previous behavior from ShortDebugString().

zhaohuabing · 2026-02-24T00:22:44Z

Hi @wbpcode @yanjunxiang-google The CI errors seem not related to this PR, and merging with main didn't fix it.

yanjunxiang-google · 2026-02-24T20:51:30Z

@zhaohuabing Please merge main again and see whether the CI error disappear!

zhaohuabing · 2026-02-26T15:12:02Z

/retest

zhaohuabing · 2026-02-26T23:48:07Z

/retest

zhaohuabing · 2026-02-28T09:27:54Z

/retest

yanjunxiang-google · 2026-02-28T16:33:25Z

LGTM

wbpcode

LGTM. Thanks.

…37 behavior under Protobuf 30+) (envoyproxy#43508) Commit Message: Envoy 1.37.0 updated protobuf from 29.3 to 33.2. That dependency change altered debug-string output semantics and broke behavior that worked in 1.36.x for ext_proc consumers parsing `xds.virtual_host_metadata`. This behavior change was introduced in envoyproxy#42435 and envoyproxy#42827. This PR switches message serialization from debug-string APIs to protobuf text-format APIs so message-valued CEL attributes are machine-parseable again, as recommended by protobuf programming guides. https://protobuf.dev/programming-guides/deserialize-debug **What broke in 1.37.0** - In both 1.36.x and 1.37.0, message-valued CEL results were stringified via ShortDebugString(). - In 1.36.x (protobuf 29.3), that output was parseable. - In 1.37.0 (protobuf 33.2), debug strings are now prefixed with `goo.gle/debugonly` / `goo.gle/debugstr`, which is intentionally non-parseable as textproto. - Result: ext_proc implementations that parse `xds.virtual_host_metadata` as textproto started failing after upgrading to 1.37.0. **Note**: xds metadata attributes in ext_proc requests are **not diagnostic log fields**; they are machine-to-machine payload data consumed by external processors. External processors parse these values to make policy and routing decisions, so serialization must be stable and machine-readable by standard protobuf tooling. `DebugString` is a diagnostic format with no compatibility contract, and in protobuf 30+ it may include `goo.gle/debug...` prefixes that intentionally break parsing. For this path, protobuf `TextFormat` is the correct format, not debug serialization. **Example** Given virtual host metadata: ```yaml { "metadata": { "filterMetadata": { "envoy-gateway": { "resources": [ { "kind": "Gateway", "name": "eg", "namespace": "default", "sectionName": "http" } ] } } } } ``` Before (1.37.0 + protobuf 30+ path), ext_proc may receive: `goo.gle/debugonly filter_metadata { key: "envoy-gateway" value { ... } }` Parsing fails at token 1. After this PR: `filter_metadata { key: "envoy-gateway" value { ... } }` This is protobuf text format and parses via TextFormat::ParseFromString(...). **Compatibility notes** - This restores 1.36.x-like effective behavior for ext_proc users (parseable metadata strings), while using the correct serialization API. - Minor formatting differences vs 1.36.x debug output are possible (whitespace/order), but output is now stable machine-readable textproto. - Scope includes other call sites using Expr::print(...) for message-valued CEL results (for example rate-limit descriptor CEL stringification). Additional Description: Risk Level: low Testing: unit and integration test Docs Changes: Release Notes: yes Platform Specific Features: [Optional Runtime guard:] [Optional Fixes #Issue] [Optional Fixes commit envoyproxy#43466] [Optional Deprecated:] [Optional [API Considerations](https://github.com/envoyproxy/envoy/blob/main/api/review_checklist.md):] --------- Signed-off-by: Huabing (Robin) Zhao <zhaohuabing@gmail.com> (cherry picked from commit 697e419) Signed-off-by: Huabing (Robin) Zhao <zhaohuabing@gmail.com>

…37 behavior under Protobuf 30+) (#43508) Commit Message: Envoy 1.37.0 updated protobuf from 29.3 to 33.2. That dependency change altered debug-string output semantics and broke behavior that worked in 1.36.x for ext_proc consumers parsing `xds.virtual_host_metadata`. This behavior change was introduced in #42435 and #42827. This PR switches message serialization from debug-string APIs to protobuf text-format APIs so message-valued CEL attributes are machine-parseable again, as recommended by protobuf programming guides. https://protobuf.dev/programming-guides/deserialize-debug **What broke in 1.37.0** - In both 1.36.x and 1.37.0, message-valued CEL results were stringified via ShortDebugString(). - In 1.36.x (protobuf 29.3), that output was parseable. - In 1.37.0 (protobuf 33.2), debug strings are now prefixed with `goo.gle/debugonly` / `goo.gle/debugstr`, which is intentionally non-parseable as textproto. - Result: ext_proc implementations that parse `xds.virtual_host_metadata` as textproto started failing after upgrading to 1.37.0. **Note**: xds metadata attributes in ext_proc requests are **not diagnostic log fields**; they are machine-to-machine payload data consumed by external processors. External processors parse these values to make policy and routing decisions, so serialization must be stable and machine-readable by standard protobuf tooling. `DebugString` is a diagnostic format with no compatibility contract, and in protobuf 30+ it may include `goo.gle/debug...` prefixes that intentionally break parsing. For this path, protobuf `TextFormat` is the correct format, not debug serialization. **Example** Given virtual host metadata: ```yaml { "metadata": { "filterMetadata": { "envoy-gateway": { "resources": [ { "kind": "Gateway", "name": "eg", "namespace": "default", "sectionName": "http" } ] } } } } ``` Before (1.37.0 + protobuf 30+ path), ext_proc may receive: `goo.gle/debugonly filter_metadata { key: "envoy-gateway" value { ... } }` Parsing fails at token 1. After this PR: `filter_metadata { key: "envoy-gateway" value { ... } }` This is protobuf text format and parses via TextFormat::ParseFromString(...). **Compatibility notes** - This restores 1.36.x-like effective behavior for ext_proc users (parseable metadata strings), while using the correct serialization API. - Minor formatting differences vs 1.36.x debug output are possible (whitespace/order), but output is now stable machine-readable textproto. - Scope includes other call sites using Expr::print(...) for message-valued CEL results (for example rate-limit descriptor CEL stringification). Additional Description: Risk Level: low Testing: unit and integration test Docs Changes: Release Notes: yes Platform Specific Features: [Optional Runtime guard:] [Optional Fixes #Issue] [Optional Fixes commit #43466] [Optional Deprecated:] [Optional [API Considerations](https://github.com/envoyproxy/envoy/blob/main/api/review_checklist.md):] --------- Signed-off-by: Huabing (Robin) Zhao <zhaohuabing@gmail.com> (cherry picked from commit 697e419) Signed-off-by: Huabing (Robin) Zhao <zhaohuabing@gmail.com>

…37 behavior under Protobuf 30+) (envoyproxy#43508) Commit Message: Envoy 1.37.0 updated protobuf from 29.3 to 33.2. That dependency change altered debug-string output semantics and broke behavior that worked in 1.36.x for ext_proc consumers parsing `xds.virtual_host_metadata`. This behavior change was introduced in envoyproxy#42435 and envoyproxy#42827. This PR switches message serialization from debug-string APIs to protobuf text-format APIs so message-valued CEL attributes are machine-parseable again, as recommended by protobuf programming guides. https://protobuf.dev/programming-guides/deserialize-debug **What broke in 1.37.0** - In both 1.36.x and 1.37.0, message-valued CEL results were stringified via ShortDebugString(). - In 1.36.x (protobuf 29.3), that output was parseable. - In 1.37.0 (protobuf 33.2), debug strings are now prefixed with `goo.gle/debugonly` / `goo.gle/debugstr`, which is intentionally non-parseable as textproto. - Result: ext_proc implementations that parse `xds.virtual_host_metadata` as textproto started failing after upgrading to 1.37.0. **Note**: xds metadata attributes in ext_proc requests are **not diagnostic log fields**; they are machine-to-machine payload data consumed by external processors. External processors parse these values to make policy and routing decisions, so serialization must be stable and machine-readable by standard protobuf tooling. `DebugString` is a diagnostic format with no compatibility contract, and in protobuf 30+ it may include `goo.gle/debug...` prefixes that intentionally break parsing. For this path, protobuf `TextFormat` is the correct format, not debug serialization. **Example** Given virtual host metadata: ```yaml { "metadata": { "filterMetadata": { "envoy-gateway": { "resources": [ { "kind": "Gateway", "name": "eg", "namespace": "default", "sectionName": "http" } ] } } } } ``` Before (1.37.0 + protobuf 30+ path), ext_proc may receive: `goo.gle/debugonly filter_metadata { key: "envoy-gateway" value { ... } }` Parsing fails at token 1. After this PR: `filter_metadata { key: "envoy-gateway" value { ... } }` This is protobuf text format and parses via TextFormat::ParseFromString(...). **Compatibility notes** - This restores 1.36.x-like effective behavior for ext_proc users (parseable metadata strings), while using the correct serialization API. - Minor formatting differences vs 1.36.x debug output are possible (whitespace/order), but output is now stable machine-readable textproto. - Scope includes other call sites using Expr::print(...) for message-valued CEL results (for example rate-limit descriptor CEL stringification). Additional Description: Risk Level: low Testing: unit and integration test Docs Changes: Release Notes: yes Platform Specific Features: [Optional Runtime guard:] [Optional Fixes #Issue] [Optional Fixes commit envoyproxy#43466] [Optional Deprecated:] [Optional [API Considerations](https://github.com/envoyproxy/envoy/blob/main/api/review_checklist.md):] --------- Signed-off-by: Huabing (Robin) Zhao <zhaohuabing@gmail.com> Signed-off-by: bjmask <11672696+bjmask@users.noreply.github.com>

…37 behavior under Protobuf 30+) (envoyproxy#43508) Commit Message: Envoy 1.37.0 updated protobuf from 29.3 to 33.2. That dependency change altered debug-string output semantics and broke behavior that worked in 1.36.x for ext_proc consumers parsing `xds.virtual_host_metadata`. This behavior change was introduced in envoyproxy#42435 and envoyproxy#42827. This PR switches message serialization from debug-string APIs to protobuf text-format APIs so message-valued CEL attributes are machine-parseable again, as recommended by protobuf programming guides. https://protobuf.dev/programming-guides/deserialize-debug **What broke in 1.37.0** - In both 1.36.x and 1.37.0, message-valued CEL results were stringified via ShortDebugString(). - In 1.36.x (protobuf 29.3), that output was parseable. - In 1.37.0 (protobuf 33.2), debug strings are now prefixed with `goo.gle/debugonly` / `goo.gle/debugstr`, which is intentionally non-parseable as textproto. - Result: ext_proc implementations that parse `xds.virtual_host_metadata` as textproto started failing after upgrading to 1.37.0. **Note**: xds metadata attributes in ext_proc requests are **not diagnostic log fields**; they are machine-to-machine payload data consumed by external processors. External processors parse these values to make policy and routing decisions, so serialization must be stable and machine-readable by standard protobuf tooling. `DebugString` is a diagnostic format with no compatibility contract, and in protobuf 30+ it may include `goo.gle/debug...` prefixes that intentionally break parsing. For this path, protobuf `TextFormat` is the correct format, not debug serialization. **Example** Given virtual host metadata: ```yaml { "metadata": { "filterMetadata": { "envoy-gateway": { "resources": [ { "kind": "Gateway", "name": "eg", "namespace": "default", "sectionName": "http" } ] } } } } ``` Before (1.37.0 + protobuf 30+ path), ext_proc may receive: `goo.gle/debugonly filter_metadata { key: "envoy-gateway" value { ... } }` Parsing fails at token 1. After this PR: `filter_metadata { key: "envoy-gateway" value { ... } }` This is protobuf text format and parses via TextFormat::ParseFromString(...). **Compatibility notes** - This restores 1.36.x-like effective behavior for ext_proc users (parseable metadata strings), while using the correct serialization API. - Minor formatting differences vs 1.36.x debug output are possible (whitespace/order), but output is now stable machine-readable textproto. - Scope includes other call sites using Expr::print(...) for message-valued CEL results (for example rate-limit descriptor CEL stringification). Additional Description: Risk Level: low Testing: unit and integration test Docs Changes: Release Notes: yes Platform Specific Features: [Optional Runtime guard:] [Optional Fixes #Issue] [Optional Fixes commit envoyproxy#43466] [Optional Deprecated:] [Optional [API Considerations](https://github.com/envoyproxy/envoy/blob/main/api/review_checklist.md):] --------- Signed-off-by: Huabing (Robin) Zhao <zhaohuabing@gmail.com>

zhaohuabing requested review from mattklein123, tyxia, yanavlasov and yanjunxiang-google as code owners February 16, 2026 06:32

zhaohuabing marked this pull request as draft February 16, 2026 06:32

zhaohuabing force-pushed the fix-43466 branch 4 times, most recently from 9a10b0b to 651180a Compare February 16, 2026 07:54

zhaohuabing marked this pull request as ready for review February 16, 2026 07:54

zhaohuabing changed the title ~~fix: message-valued CEL attributes have a goo.gle/debugonly prefix~~ fix: use TextFormat for message-valued CEL attributes (restore pre-1.37 behavior under Protobuf 30+) Feb 16, 2026

zhaohuabing marked this pull request as draft February 16, 2026 08:11

zhaohuabing force-pushed the fix-43466 branch from 651180a to d5a5d7f Compare February 16, 2026 09:44

zhaohuabing marked this pull request as ready for review February 16, 2026 09:45

botengyao assigned wbpcode Feb 18, 2026

zhaohuabing force-pushed the fix-43466 branch 3 times, most recently from 3e06f0f to 86b71dd Compare February 19, 2026 13:08

zhaohuabing added 2 commits February 22, 2026 04:37

use TextFormat for message-valued CEL attributes

6343a2e

Signed-off-by: Huabing (Robin) Zhao <zhaohuabing@gmail.com>

add runtime guard

742a4a4

Signed-off-by: Huabing (Robin) Zhao <zhaohuabing@gmail.com>

zhaohuabing force-pushed the fix-43466 branch from 86b71dd to 742a4a4 Compare February 22, 2026 04:38

wbpcode previously approved these changes Feb 22, 2026

View reviewed changes

yanjunxiang-google mentioned this pull request Feb 23, 2026

ext_proc: xds.virtual_host_metadata unparseable due to DebugString serialization (Envoy 1.37.0) #43466

Open

yanjunxiang-google reviewed Feb 23, 2026

View reviewed changes

yanjunxiang-google previously approved these changes Feb 23, 2026

View reviewed changes

Merge remote-tracking branch 'origin/main' into fix-43466

73828d5

zhaohuabing dismissed stale reviews from yanjunxiang-google and wbpcode via 73828d5 February 24, 2026 00:01

zhaohuabing requested review from wbpcode and yanjunxiang-google February 24, 2026 00:10

zhaohuabing added 2 commits February 26, 2026 16:10

Merge remote-tracking branch 'origin/main' into fix-43466

2686360

Merge remote-tracking branch 'origin/main' into fix-43466

35dd2d5

zhaohuabing added 2 commits February 27, 2026 02:53

Merge remote-tracking branch 'origin/main' into fix-43466

08f0840

Merge remote-tracking branch 'origin/main' into fix-43466

aa6c472

wbpcode approved these changes Mar 2, 2026

View reviewed changes

wbpcode merged commit 697e419 into envoyproxy:main Mar 2, 2026
28 checks passed

zhaohuabing deleted the fix-43466 branch March 2, 2026 04:41

Conversation

zhaohuabing commented Feb 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

zhaohuabing commented Feb 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

wbpcode commented Feb 18, 2026

Uh oh!

repokitteh-read-only Bot commented Feb 19, 2026

Uh oh!

wbpcode left a comment

Choose a reason for hiding this comment

Uh oh!

yanjunxiang-google commented Feb 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

yanjunxiang-google Feb 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

zhaohuabing Feb 24, 2026

Choose a reason for hiding this comment

Uh oh!

zhaohuabing commented Feb 24, 2026

Uh oh!

yanjunxiang-google commented Feb 24, 2026

Uh oh!

zhaohuabing commented Feb 26, 2026

Uh oh!

zhaohuabing commented Feb 26, 2026

Uh oh!

zhaohuabing commented Feb 28, 2026

Uh oh!

yanjunxiang-google commented Feb 28, 2026

Uh oh!

wbpcode left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

zhaohuabing commented Feb 16, 2026 •

edited

Loading

zhaohuabing commented Feb 16, 2026 •

edited

Loading

yanjunxiang-google commented Feb 23, 2026 •

edited

Loading

yanjunxiang-google Feb 23, 2026 •

edited

Loading