deps: Update protobuf to 33.2#42827
Merged
Merged
Conversation
Fixes: envoyproxy#42442 Signed-off-by: Alejandro R. Sedeño <asedeno@google.com>
repokitteh-read-only
Bot
added
the
deps
|
CC @envoyproxy/dependency-shepherds: Your approval is needed for changes made to |
agrawroh
approved these changes
Jan 3, 2026
repokitteh-read-only
Bot
removed
the
deps
Member
|
can we hold off on this change - we have an imminent release and no burn-in time |
Member
|
/wait |
wbpcode
pushed a commit
that referenced
this pull request
Mar 2, 2026
…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>
zhaohuabing
added a commit
to zhaohuabing/envoy
that referenced
this pull request
Mar 2, 2026
…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>
phlax
pushed a commit
that referenced
this pull request
Mar 2, 2026
…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>
bmjask
pushed a commit
to bmjask/envoy
that referenced
this pull request
Mar 14, 2026
…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>
bvandewalle
pushed a commit
to bvandewalle/envoy
that referenced
this pull request
Mar 17, 2026
…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>
grnmeira
pushed a commit
to grnmeira/envoy
that referenced
this pull request
Mar 20, 2026
Risk Level: low Testing: CI Fixes: envoyproxy#42442 Signed-off-by: Alejandro R. Sedeño <asedeno@google.com> Signed-off-by: Gustavo <grnmeira@gmail.com>
fishcakez
pushed a commit
to fishcakez/envoy
that referenced
this pull request
Mar 25, 2026
…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>
krinkinmu
pushed a commit
to grnmeira/envoy
that referenced
this pull request
Apr 20, 2026
…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>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Risk Level: low
Testing: CI
Fixes: #42442