{ "schemaVersion": 3, "dataset": { "version": 3, "date": "2026-08-13", "group": { "id": "platform-infrastructure", "name": "Platform / Networking / Runtime Infrastructure" }, "repository": { "id": "envoy", "repo": "envoyproxy/envoy", "name": "Envoy", "keywords": [ "Envoy Proxy" ] }, "context": { "repository": "envoyproxy/envoy", "url": "https://github.com/envoyproxy/envoy", "description": "Cloud-native high-performance edge/middle/service proxy", "homepage": "https://www.envoyproxy.io", "language": "C++", "topics": [ "cars", "cats", "cats-over-dogs", "cncf", "corgis", "more-cats", "nanoservices", "rocket-ships" ], "license": "Apache-2.0", "defaultBranch": "main", "stars": 28771, "forks": 5553, "openIssues": 1836, "archived": false, "collectedAt": "2026-08-13T18:01:58.719902+00:00" }, "news": { "repository": "envoyproxy/envoy", "collectedAt": "2026-08-13T18:01:58.719902+00:00", "latestRelease": { "repository": "envoyproxy/envoy", "tag": "v1.39.0", "title": "v1.39.0", "url": "https://github.com/envoyproxy/envoy/releases/tag/v1.39.0", "publishedAt": "2026-07-14T22:03:18Z", "notes": "## Summary of changes\r\n\r\n## Breaking changes\r\n\r\n- **build**: Envoy now uses Bazel 8. Because Envoy still uses WORKSPACE mode, `--enable_workspace` and `--noenable_bzlmod` are required and have been added to `.bazelrc`; external-repository runfiles now appear directly under the runfiles root.\r\n- **build**: the Intel DLB connection balancer (`envoy.network.connection_balance.dlb`) is disabled for all builds due to a broken source archive.\r\n- **TLS**: `enforce_rsa_key_usage` is deprecated and ignored; Envoy now always enforces the certificate `keyUsage` extension.\r\n- **TLS inspector**: client TLS versions are validated and must be between TLS 1.0 and TLS 1.3 (revertible via `envoy.reloadable_features.tls_inspector_enforce_client_tls_version`).\r\n- **OpenTelemetry tracing**: the tracer now honors Envoy's request-entry sampling decision, including `overall_sampling`, even when propagated trace context or the configured sampler requests sampling. This may reduce exported spans.\r\n\r\n### Security\r\n- HTTP/2 now counts uncompressed cookies toward header-size and header-count limits (**CVE-2026-47774**), strengthens PRIORITY/WINDOW_UPDATE flood protection, and adds configurable nghttp2 RST_STREAM rate limits.\r\n- HTTP/3 fixes cover QPACK blocked-decoding denial of service (**GHSA-p7c7-7c47-pwch**) and inconsistent headers-only `content-length` handling (**CVE-2026-48743**).\r\n- Security fixes were added for ext_authz (**CVE-2026-47205**), ext_proc (**CVE-2026-47207**), gRPC stats (**CVE-2026-47204**), internal redirects (**CVE-2026-47221**), and OAuth2 lifecycle handling (**CVE-2026-48090**).\r\n- OAuth2 adds AES-256-GCM cookie encryption to address **CVE-2026-47775**. Migration is opt-in: enable `oauth2_use_gcm_encryption`, monitor `oauth_legacy_cbc_decrypt`, then disable `oauth2_legacy_cbc_decrypt_compat`.\r\n- Additional fixes cover DNS query validation (**CVE-2026-48497**), JSON nesting limits (**CVE-2026-48042**), PROXY protocol TLV smuggling (**CVE-2026-47692**), formatter crashes (**CVE-2026-47220**), TCP StatsD overflow (**CVE-2026-48706**), TLS SAN NUL handling (**CVE-2026-47778**), and Zstd decompression memory exhaustion (**CVE-2026-48044**).\r\n- New upstream RBAC and dynamic-forward-proxy resolved-address filtering provide CIDR-based protection against SSRF after DNS resolution and host selection.\r\n\r\n### Dynamic modules\r\n- New extension points: access-log/header formatters, downstream and upstream transport sockets, active health checkers, and stats sinks.\r\n- Cluster load balancers can read host stats, read and write dynamic metadata and filter state, and publish main-thread state to worker-local slots.\r\n- Modules can emit metrics from configuration and background contexts; loading and initialization failures now expose server-wide counters tagged by extension instance.\r\n- Added validation-mode detection, network/listener attribute access, batched header and metadata APIs, effective log-level access, and zero-copy borrowed buffers in the Rust SDK.\r\n- Fixed listener HTTP-callout crashes, watermark initialization, streaming-response re-entry, independent decode/encode continuation, CatchUnwind re-entry, `Struct` configuration handling, and HTTP/TCP bridge buffer overflow with more than 64 slices.\r\n\r\n### MCP (Model Context Protocol) and AI protocols\r\n- Added a Wuffs-backed streaming JSON parser for MCP, A2A, OpenAI, Anthropic, and related protocols, with bounded field capture, incremental parsing, no DOM allocation, and duplicate-key detection.\r\n- MCP filtering now exposes processing status, supports configurable duplicate-key rejection, and improves oversized-body behavior for pass-through and rejection modes.\r\n- MCP router adds elicitation and server-to-client request routing, plus lazy per-backend initialization.\r\n- MCP JSON REST Bridge adds per-route tool configuration and locally generated `tools/list` responses.\r\n\r\n### HTTP, routing and protocol\r\n- New HTTP filters provide weighted bandwidth sharing and selectable sub-filter chains with per-route configuration.\r\n- `HeaderMatcher` now evaluates separately supplied header values individually instead of matching only their comma-joined representation (revertible via `envoy.reloadable_features.match_headers_individually`).\r\n- HTTP inspector uses Balsa by default and now fast-fails invalid non-HTTP method bytes instead of buffering up to 64 KiB.\r\n- Added drain-timeout and maximum-connection-duration jitter to reduce synchronized reconnect spikes.\r\n- Routing gains cluster refresh on retries, weighted-cluster reselection, formatter/CEL-based redirect paths, and mixed literal/variable URI-template segments.\r\n- Fixed connection-pool re-entrancy, connectivity-grid teardown and duplicate-attempt bugs, stale on-demand cluster information, and handling of HTTP/2 or HTTP/3 `RST_STREAM(NO_ERROR)` after complete responses.\r\n\r\n### TLS, authentication and authorization\r\n- Added CNSA 1.0/2.0 compliance policies, TLS group formatters for identifying post-quantum key exchange, and suppression of oversized client CA lists.\r\n- QUIC supports opt-in TLS key logging and session-ticket resumption.\r\n- TLS certificate compression via the brotli runtime guard is disabled by default; TLS sockets also gain improved connection-reset reporting.\r\n- OAuth2 adds `PRIVATE_KEY_JWT`, ID-token forwarding, configurable post-logout redirects, access-token-based cookie lifetime, and safe original-request URI formatting with redirect-domain allowlists.\r\n- BasicAuth supports missing-credential pass-through and authenticated-username metadata; JWT extraction can mark forwarded claims whose signatures were not verified.\r\n\r\n### DNS, load balancing and upstream\r\n- The unified DNS cluster implementation is enabled by default; equivalent c-ares resolvers can be shared across clusters to support shared qcache.\r\n- DNS clusters gain a minimum TTL refresh floor, while dynamic forward proxy sub-clusters can use `DnsCluster` configuration and resolved-address CIDR filtering.\r\n- Client-side weighted round robin adds out-of-band ORCA reporting with configurable port, authority, and transport socket matching.\r\n- Least-request load balancing can optionally account for pending requests, with a new per-endpoint pending-request gauge.\r\n- Fixed EDS hostname updates, load reports containing only custom metrics or completed requests, and dynamic-forward-proxy lookup teardown.\r\n\r\n### Networking and system performance\r\n- Linux deployments gain worker CPU affinity and an `SO_REUSEPORT` BPF connection balancer for CPU-local connection steering.\r\n- Added a Linux sockmap socket interface for accelerating same-host TCP traffic through eBPF.\r\n- io_uring adds multishot receives, adaptive read buffers, and configurable write backpressure.\r\n- Reverse tunnels gain opt-in GOAWAY-aware draining and replacement; MySQL proxy adds downstream TLS termination with `caching_sha2_password` mediation.\r\n- Added UDP proxy external authorization, network ext_proc metadata reception, and early external-processor stream closure.\r\n\r\n### Observability\r\n- New access-log data includes upstream TLS SNI and HTTP/TCP downstream/upstream connection duration points; gRPC access logging adds delivery success/failure counters.\r\n- Added dynamic-module and Wasm programmable stats sinks, OpenTelemetry metric request chunking, endpoint observability names, and default-tag overrides.\r\n- Prometheus scraping and large-scale stat-reference release are substantially faster; `/peak_heap_dump` exposes tcmalloc's peak heap profile.\r\n- Added process-wide Lua and Wasm VM gauges, single-entry stack traces, and an Envoy-version log-format token.\r\n- Tap now honors configured runtime sampling and reports sampled-out requests/connections.\r\n\r\n### Rate limiting and configuration\r\n- Rate limiting adds static and dynamic per-descriptor limit overrides, zero-token always-reject behavior, and configurable response-metadata namespaces.\r\n- GCP authentication supports bound access tokens, bound JWTs, and unbound access tokens from the metadata server.\r\n- Added file-backed IP tagging, in-place watched-file modification events, runtime-adjustable fixed-heap limits, health-check HTTP status events, and xDS unsubscribe callbacks.\r\n- Redis proxy adds Redis 7.4 hash-field expiry commands and permits custom commands inside transactions.\r\n\r\n### Other notable changes and fixes\r\n- Fixed Hickory DNS resolver leaks and use-after-free, file-server cancellation use-after-free, Golang filter re-entry, outlier-detection teardown, missing network namespaces, and asynchronous TLS close handling.\r\n- Fixed RTDS guard removal, VHDS subscriptions, Wasm VM cache invalidation when environment variables change, and upstream Wasm metric scoping.\r\n- Improved UDP proxy attempted-host and address logging, Zipkin timestamp trace IDs, gRPC access-log failure accounting, and health-check event detail.\r\n- Added TCP proxy delayed route selection, drain-close handling, and connection-duration access logging.\r\n\r\n**Docker images**:\r\n https://hub.docker.com/r/envoyproxy/envoy/tags?page=1&name=v1.39.0\r\n**Docs**:\r\n https://www.envoyproxy.io/docs/envoy/v1.39.0/\r\n**Release notes**:\r\n https://www.envoyproxy.io/docs/envoy/v1.39.0/version_history/v1.39/v1.39.0\r\n**Full changelog**:\r\n https://github.com/envoyproxy/envoy/compare/v1.38.0...v1.39.0\r\n\r\n\r\nSigned-off-by: Kateryna Nezdolii [kateryna.nezdolii@gmail.com](mailto:kateryna.nezdolii@gmail.com)\r\nSigned-off-by: Ryan Northey [ryan@synca.io](mailto:ryan@synca.io)\r\nSigned-off-by: Jonh Wendell [jwendell@redhat.com](mailto:jwendell@redhat.com)\r\n", "highlights": [ "Summary of changes", "Breaking changes", "build: Envoy now uses Bazel 8. Because Envoy still uses WORKSPACE mode, --enableworkspace and --noenablebzlmod are required and have been added to .bazelrc; external-repository runfiles now appear directly under the runfiles root.", "build: the Intel DLB connection balancer (envoy.network.connectionbalance.dlb) is disabled for all builds due to a broken source archive.", "TLS: enforcersakeyusage is deprecated and ignored; Envoy now always enforces the certificate keyUsage extension.", "TLS inspector: client TLS versions are validated and must be between TLS 1.0 and TLS 1.3 (revertible via envoy.reloadablefeatures.tlsinspectorenforceclienttlsversion)." ], "prerelease": false }, "upcoming": [ { "repository": "envoyproxy/envoy", "kind": "milestone", "title": "Publicly available signed binaries/releases", "url": "https://github.com/envoyproxy/envoy/milestone/36", "description": "", "progress": 78, "openIssues": 2, "closedIssues": 7 }, { "repository": "envoyproxy/envoy", "kind": "milestone", "title": "Stabilizing the Golang filter", "url": "https://github.com/envoyproxy/envoy/milestone/48", "description": "The recently added Golang filter has a number of steps in its roadmap, some known issues and is going through some initial burnin. This milestone is to group issues and PRs", "progress": 92, "openIssues": 1, "closedIssues": 12 }, { "repository": "envoyproxy/envoy", "kind": "milestone", "title": "Switch to bzlmod", "url": "https://github.com/envoyproxy/envoy/milestone/106", "description": "", "progress": 50, "openIssues": 1, "closedIssues": 1 } ], "communityDiscussions": [] }, "runs": [ { "collectedAt": "2026-08-13T12:26:38.318Z", "since": "2026-08-12T12:26:38.318Z", "observedCount": 64, "changedCount": 64 }, { "collectedAt": "2026-08-13T13:48:00.446149Z", "since": "2026-08-12T13:48:00.446149Z", "observedCount": 65, "changedCount": 65 }, { "collectedAt": "2026-08-13T16:19:22.035158Z", "since": "2026-08-12T16:19:22.035158Z", "observedCount": 64, "changedCount": 19 }, { "collectedAt": "2026-08-13T17:43:20.785491Z", "since": "2026-08-12T17:43:20.785491Z", "observedCount": 62, "changedCount": 7 }, { "collectedAt": "2026-08-13T17:47:07.884300Z", "since": "2026-08-12T17:47:07.884300Z", "observedCount": 63, "changedCount": 1 }, { "collectedAt": "2026-08-13T18:01:55.420671Z", "since": "2026-08-12T18:01:55.420671Z", "observedCount": 63, "changedCount": 0 } ], "signals": [ { "id": "github:envoyproxy/envoy:issue:28566", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "issue", "title": "Shift `clang-tidy` to github action", "text": "Currently clang-tidy is not working very well and need some attention I am gradually picking off various bits of ci for shifting azp -> gh This one seems like quite a good candidate to start on the checks with.", "url": "https://github.com/envoyproxy/envoy/issues/28566", "createdAt": "2023-07-22T12:30:31Z", "updatedAt": "2026-08-13T13:25:10Z", "timestamp": "2026-08-13T13:25:10Z", "metrics": { "reactions": 0, "comments": 48 }, "labels": [ "no stalebot", "area/clang-tidy", "area/github-migration" ], "author": "phlax", "state": "open", "assignees": [ "jwendell" ] }, { "id": "github:envoyproxy/envoy:issue:41065", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "issue", "title": "Add Support for JA4Latency FingerPrint Hash", "text": "*Title*: *One line description* *Description*: >Describe the desired behavior, what scenario it enables and how it would be used. Envoy Proxy supports JA3 and JA4 Fingerprint Hashes today https://www.envoyproxy.io/docs/envoy/latest/api-v3/extensions/filters/listener/tls_inspector/v3/tls_inspector.proto.html#extensions-filters-listener-tls-inspector-v3-tlsinspector Would be great to also support JA4Latency https://blog.foxio.io/ja4+-network-fingerprinting which helps understand client locality useful from a security perspective [optional *Relevant Links*:] >Any extra documentation required to understand the issue.", "url": "https://github.com/envoyproxy/envoy/issues/41065", "createdAt": "2025-09-12T16:28:40Z", "updatedAt": "2026-08-13T08:27:23Z", "timestamp": "2026-08-13T08:27:23Z", "metrics": { "reactions": 1, "comments": 10 }, "labels": [ "enhancement", "area/tls", "stale", "area/tls_inspector" ], "author": "arkodg", "state": "closed", "assignees": [ "agrawroh" ] }, { "id": "github:envoyproxy/envoy:issue:45866", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "issue", "title": "Guidance on RPM packaging of official release binaries for RHEL/Rocky Linux", "text": "I want to package the official Envoy binary from GitHub releases (e.g., envoy-1.38.3-linux-x86_64) into an RPM for Rocky Linux 9 VM. A few questions: 1. What is the recommended package name when redistributing the official binary as an RPM ? 2. What files should be included for license compliance? Is LICENSE + NOTICE from the repo sufficient? 3. Is there a published GPG public key to verify the signature on checksums.txt.asc? 4. The install docs cover Debian via apt.envoyproxy.io but not RHEL-family. Is self-packaging from GitHub release binaries the recommended approach, or is an RPM repo planned? Relevant Links: - #16867 - #16830 - https://www.envoyproxy.io/docs/envoy/latest/start/install (https://www.envoyproxy.io/docs/envoy/latest/start/install)", "url": "https://github.com/envoyproxy/envoy/issues/45866", "createdAt": "2026-06-28T11:00:39Z", "updatedAt": "2026-08-12T20:11:29Z", "timestamp": "2026-08-12T20:11:29Z", "metrics": { "reactions": 0, "comments": 6 }, "labels": [ "question", "stale", "area/install" ], "author": "SHWETHABHAT1", "state": "closed", "assignees": [] }, { "id": "github:envoyproxy/envoy:issue:46104", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "issue", "title": "openssl compat: implement CNSA1_202603 compliance policy", "text": "## Description The OpenSSL compat layer does not implement the `ssl_compliance_policy_cnsa1_202603` case in `SSL_CTX_set_compliance_policy`. When a user configures CNSA1 on an Envoy build using OpenSSL, the TLS context creation fails and Envoy refuses to start. BoringSSL implements CNSA1 natively via `SSL_CTX_set_compliance_policy(ssl_compliance_policy_cnsa1_202603)`, which configures: - TLS 1.2 or TLS 1.3 - For TLS 1.2, only `TLS_ECDHE_[ECDSA|RSA]_WITH_AES_256_GCM_SHA384` - For TLS 1.3, only AES-256-GCM - ML-KEM-1024 or P-384 for key agreement, preferring ML-KEM-1024 - For handshake signatures, only ECDSA with P-384/SHA-384 or RSA with SHA-384 ## What's needed A full implementation in the compat layer requires: 1. **ML-KEM-1024 TLS group support** — OpenSSL 3.5+ supports ML-KEM-1024 as a cryptographic primitive and has hybrid groups like `SecP384r1MLKEM1024`, but the compat layer has the group mappings commented out (`ossl_NID_MLKEM1024`). These need to be enabled and tested first. 2. **TLS 1.3 ciphersuite restriction** — The compat layer needs to restrict TLS 1.3 to AES-256-GCM only (via `SSL_CTX_set_ciphersuites` in OpenSSL). 3. **Signature algorithm and key agreement configuration** — P-384 group, SHA-384 signature algorithms, and server cipher preference. These are straightforward using existing compat layer patterns. ## Context - CNSA1 support was added to Envoy in #46089 - The compat layer currently returns 0 (unsupported) for this policy, which is the correct behavior until a full implementation is available - Relevant file: `compat/openssl/source/SSL_CTX_set_compliance_policy.cc`", "url": "https://github.com/envoyproxy/envoy/issues/46104", "createdAt": "2026-07-13T19:44:39Z", "updatedAt": "2026-08-13T00:12:48Z", "timestamp": "2026-08-13T00:12:48Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [ "area/tls", "stale" ], "author": "jwendell", "state": "open", "assignees": [ "jwendell" ] }, { "id": "github:envoyproxy/envoy:issue:46114", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "issue", "title": "tls: share parsed CA trust store (X509_STORE) across contexts built from identical CA material", "text": "## Title tls: share parsed CA trust store (`X509_STORE`) across contexts built from identical CA material ## Problem Envoy builds a parsed CA trust store (`X509_STORE`) once per `Ssl::ContextImpl`, and a `ContextImpl` is created once per transport-socket factory — i.e. once per cluster, and again on every SDS rotation. When many clusters validate against the **same** CA bundle, Envoy re-parses that bundle (PEM → X509 → ASN.1) into a separate store per cluster. There is no content-addressed sharing, so memory grows with **(#clusters) × (CA bundle size)** instead of with the number of distinct CAs. This is the pathology Envoy already fixed for CRLs via `CrlCache`, never extended to the CA store. ## Why it happens - `ContextManagerImpl::createSslClientContext` never dedups by content — it builds a fresh `ClientContextImpl` every call (`context_manager_impl.cc:30`); `contexts_` is a pointer-keyed set for stats only. - Each `ContextImpl` allocates its own `SSL_CTX`/store (`context_impl.cc:107`), and the validator re-parses the CA into it with no cache lookup (`default_validator.cc:147-160`). - Sharing at SDS doesn't help: SDS dedups raw bytes by name (`secret_manager_impl.h:88`), but each subscribing factory still rebuilds a full store on load and rotation (`context_config_impl.cc:318`, `client_ssl_socket.cc:47`). ## Evidence Heap profiling of a gateway with many clusters sharing one corporate CA shows ~90% of the data-plane heap under upstream TLS validation: ``` Ssl::ClientContextImpl -> ContextImpl -> DefaultCertValidator -> BoringSSL PEM_X509_INFO_read / x_x509 / asn1 parsing -> malloc ``` Reducing worker concurrency doesn't lower it — confirming per-context, not per-worker, state. ## Impact Deployments with many backends behind a shared CA can use multiple GB at idle, scaling with cluster count rather than distinct-CA count. Common for gateways/meshes that emit one cluster per route destination, each referencing the same CA. ## Proposal Add a process-wide, content-addressed trust-store cache, modeled on the existing `CrlCache` (`default_validator.cc:52-93`), so contexts with identical CA material + store-affecting settings share one refcounted `X509_STORE`. ## Precedent `CrlCache` (`default_validator.cc:52-93`) is this exact pattern for CRLs — singleton, keyed on `SHA256(crl_pem)`, refcounted, `weak_ptr` eviction. Its doc comment (`default_validator.h:56-70`) describes this very problem (\"parsed and held in memory once per context\"). This generalizes it to the CA store.", "url": "https://github.com/envoyproxy/envoy/issues/46114", "createdAt": "2026-07-14T08:11:13Z", "updatedAt": "2026-08-13T08:27:33Z", "timestamp": "2026-08-13T08:27:33Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [ "stale" ], "author": "zhaohuabing", "state": "open", "assignees": [] }, { "id": "github:envoyproxy/envoy:issue:46505", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "issue", "title": "http1: unsafe ctype usage and size_t to int narrowing in the HTTP/1 parser", "text": "*Title*: http1: unsafe ctype usage and size_t to int narrowing in the HTTP/1 parser *Description*: Two type-safety defects in the HTTP/1 parser, found while working on #46496. Neither appears to be a security issue. There's no crash, no memory-safety consequence on supported platforms, and no reachable trigger for (2), so I'm raising publicly. Happy to move this to a security advisory if a maintainer disagrees. **1. ctype calls on raw `char` in `isUrlValid()`** - `balsa_parser.cc:114,120,139` `std::isalpha`/`isdigit`/`isalnum` require an argument representable as `unsigned char` or `EOF`. Where `char` is signed (x86-64 Linux), a request-target byte >= 0x80 arrives as a negative `int` which is undefined behaviour, and reachable from untrusted input: `isUrlValid()` is called from `OnRequestFirstLineInput()` (line 330), and line 114 runs before any range check, because line 105 only short-circuits targets beginning `/` or `*`. These functions are also locale-sensitive by contract. No impact in practice: glibc's ctype table is defined for -128..255, musl handles negatives, and Envoy never calls `setlocale`. `isVersionValid()` in the same file (line 164) already uses `absl::ascii_isdigit`. Switching the three sites to the `absl::ascii_*` equivalents is locale-independent and well-defined, and `absl/strings/ascii.h` is already included. Happy to send that PR. **2. `size_t` to `int` narrowing on the parse path** - `parser.h:121` `Parser::execute()` takes `int len`, but is fed `RawSlice::len_` (a `size_t`, `buffer.h:32`) via `dispatchSlice()` (`codec_impl.cc:668`). A slice above `INT_MAX` truncates negative; every guard in `BalsaParser::execute()` tests `> 0` or `== 0` (lines 217, 238, 245), so all are skipped and line 251 hands the negative value to `BalsaFrame::ProcessInput()`, where it widens to a large `size_t`. `LegacyHttpParserImpl` has the same shape (`legacy_parser_impl.cc:83,141`). The bound on the returned count in `codec_impl.cc` is a debug-only `ASSERT`. Envoy's read path never produces slices near 2 GB, so this is latent rather than triggerable. The fix touches `Parser`, `BalsaParser` and `LegacyHttpParserImpl` - worth a maintainer's view on scope before anyone writes it. [optional *Relevant Links*:] 1. https://github.com/envoyproxy/envoy/pull/46496 - the PR this was found alongside 2. https://en.cppreference.com/w/cpp/string/byte/isalpha - argument requirements for the ctype functions", "url": "https://github.com/envoyproxy/envoy/issues/46505", "createdAt": "2026-08-01T18:55:47Z", "updatedAt": "2026-08-13T10:42:05Z", "timestamp": "2026-08-13T10:42:05Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [ "bug", "area/http" ], "author": "guy-with-a-why", "state": "open", "assignees": [] }, { "id": "github:envoyproxy/envoy:issue:46531", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "issue", "title": "GeoIP LookupResult is always const, inhibiting move semantics", "text": "*Description*: In `envoy/geoip/geoip_provider_driver.h`, the type `LookupResult` is defined as an alias to `const absl::flat_hash_map`. The type is usually passed around by rvalue-reference: ``` // from source/extensions/filters/http/geoip/geoip_filter.cc driver_->lookup( Geolocation::LookupRequest{std::move(remote_address)}, [self, &dispatcher = decoder_callbacks_->dispatcher()](Geolocation::LookupResult&& result) { dispatcher.post([self, result]() { if (GeoipFilterSharedPtr filter = self.lock()) { filter->onLookupComplete(std::move(result)); } }); }); ``` Hiding the `const` in the type like this makes the code confusing and makes it impossible to move a `LookupResult`. In the code above for instance, the `result` could be moved into the lambda instead of copied. It can also trigger linters that check for unnecessary uses of `std::move`, for people who have those enabled. I would be willing to refactor this if you're open to it. I think it would not be a big change, just remove the `const` and maybe add some `move`s to take advantage of it. But I thought I'd ask in case this `const` is intended like this.", "url": "https://github.com/envoyproxy/envoy/issues/46531", "createdAt": "2026-08-04T10:15:01Z", "updatedAt": "2026-08-12T21:12:39Z", "timestamp": "2026-08-12T21:12:39Z", "metrics": { "reactions": 0, "comments": 5 }, "labels": [ "enhancement", "area/geoip" ], "author": "syntax-case", "state": "open", "assignees": [] }, { "id": "github:envoyproxy/envoy:issue:46539", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "issue", "title": "Migrate build system from WORKSPACE to bzlmod", "text": "## Summary Envoy currently uses WORKSPACE mode with bzlmod explicitly disabled (`.bazelrc`: `--noenable_bzlmod`, `--enable_workspace`), despite using Bazel 8.7.0 where bzlmod is the default. A minimal `MODULE.bazel` exists with 12 `bazel_dep` entries but is inactive. The [toolshed registry](https://github.com/envoyproxy/toolshed/tree/main/bazel-registry/modules) already packages ~69 modules for bzlmod, and `api/MODULE.bazel` has a working bzlmod setup with module extensions that can serve as a template. Prior art: #42890 (stalled) demonstrated a working all-at-once migration (~139 files, +2966/-4618 lines). This issue tracks an incremental approach. ## Approach Per maintainer feedback: avoid a \"half migration\" that just wraps `repository_locations.bzl` as module extensions. Instead, convert deps directly to proper `bazel_dep` entries using the toolshed registry (and BCR for standard deps). Module extensions should only be used for the small number of deps that genuinely have no module in any registry. Toolshed itself (`envoy_toolshed`) should be pulled as a proper bzlmod module. ## Plan ### Phase 0 — Pre-work (in envoy repo, no functional change) - [x] Sync `MODULE.bazel` versions with `repository_locations.bzl` (#46540) - [x] Add `bzlmod` parameter to `envoy_dependencies()` (default `False`, skips WORKSPACE-only deps when `True`) (#46540) ### Phase 1 — Toolshed registry updates (in envoyproxy/toolshed) Update stale modules to match envoy main. Major version gaps: | Module | Envoy version | Toolshed version | |---|---|---| | wasmtime | 45.0.2 | 24.0.0 | | v8 | 14.6.202.10 | 13.8.258.26 | | protobuf | 35.1 | 33.4 | | grpc | 1.83.0 | 1.76.0 | | simdutf | 8.1.0 | 7.3.4 | Plus ~19 modules with minor/patch gaps (opentelemetry-cpp, perfetto, thrift, libevent, liburing, rules_rust, etc.). ### Phase 2 — Enable hybrid mode and migrate deps (in envoy repo) - [ ] Enable `--enable_bzlmod` alongside `--enable_workspace` in `.bazelrc` - [ ] Add toolshed registry URL to `.bazelrc` - [ ] Pull `envoy_toolshed` as a proper `bazel_dep` from the toolshed registry - [ ] Move deps to `bazel_dep` entries — start with deps already matching in toolshed registry (~35 modules) and BCR (abseil-cpp, googletest, fmt, re2, etc.) - [ ] For each dep moved to `bazel_dep`, guard its `external_http_archive` call behind the `bzlmod` flag in `envoy_dependencies()` - [ ] Add module extensions only for deps that can't be `bazel_dep` (e.g., quiche with custom BUILD file) ### Phase 3 — Migrate toolchains and remaining infrastructure - [ ] Migrate toolchain setup to `MODULE.bazel` (LLVM, Go, Rust, Python/pip) - [ ] Migrate `envoy_repo()` to a module extension - [ ] Update BUILD files for any dep name changes (use `repo_name` on `bazel_dep` where possible to minimize churn) ### Phase 4 — Flip and cleanup - [ ] Switch to `--noenable_workspace` in `.bazelrc` - [ ] Remove old WORKSPACE loading pipeline (`bazel/repositories.bzl`, `bazel/repository_locations.bzl`, etc.) - [ ] Delete patches and custom BUILD files absorbed by registry modules ## Key decisions - **Use toolshed registry, not BCR** — BCR modules make assumptions that don't match Envoy's needs. Standard deps (abseil, rules_cc, etc.) can still come from BCR. - **No half-migration** — don't just wrap `repository_locations.bzl`/`envoy_dependencies()` in module extensions. Convert deps to proper `bazel_dep` entries individually. - **Prefer `bazel_dep(repo_name=...)` over renaming** — legacy dep names (e.g., `@com_github_grpc_grpc`) can't be safely renamed in WORKSPACE mode because deps internally hardcode them. `bazel_dep(repo_name=...)` avoids the need. - **`quiche` is the holdout** — the one dep that couldn't go into a registry in #42890, needs a module extension. ## References - Prior art: #42890 - Toolshed registry: https://github.com/envoyproxy/toolshed/tree/main/bazel-registry/modules - Bazel bzlmod docs: https://bazel.build/external/overview#bzlmod", "url": "https://github.com/envoyproxy/envoy/issues/46539", "timestamp": "2026-08-12T13:27:29Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [ "area/build" ], "author": "jwendell", "assignees": [], "change": "new" }, { "id": "github:envoyproxy/envoy:issue:46584", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "issue", "title": "http2: allow configuring upstream headers as HPACK never indexed", "text": "*Title*: http2: allow configuring upstream headers as HPACK never indexed *Description*: Envoy should allow operators to configure HTTP/2 request headers to use HPACK's \"Literal Header Field Never Indexed\" representation when forwarding requests to an upstream. This is useful for high-cardinality values such as request IDs, trace IDs, or per-request tokens. These values are unlikely to be reused, so adding them to the dynamic HPACK table provides little compression benefit while causing unnecessary insertions, lookups, and evictions. Marking them as never indexed avoids this table churn and can reduce CPU usage in Envoy and the upstream HTTP/2 decoder. Envoy terminates the downstream HTTP/2 connection and creates a separate upstream HTTP/2 connection. Therefore, the client's HPACK indexing decision cannot be preserved automatically. Envoy must apply the configured policy when it re-encodes the headers for the upstream connection. Example configuration: ```yaml static_resources: clusters: - name: upstream connect_timeout: 2s type: STRICT_DNS load_assignment: cluster_name: upstream endpoints: - lb_endpoints: - endpoint: address: socket_address: address: upstream.example.com port_value: 8080 typed_extension_protocol_options: envoy.extensions.upstreams.http.v3.HttpProtocolOptions: \"@type\": type.googleapis.com/envoy.extensions.upstreams.http.v3.HttpProtocolOptions explicit_http_config: http2_protocol_options: headers_to_never_index: - x-request-id - x-trace-id - x-high-cardinality-token ``` Configured headers are forwarded unchanged, but their upstream HTTP/2 header fields are encoded using the never-indexed representation. Headers not listed in the configuration retain their existing HPACK indexing behavior. *Relevant Links*: - [POC Implementation branch](https://github.com/petedmarsh/envoy/tree/http2-never-index-headers) - [RFC 7541 section 6.2.3: Literal Header Field Never Indexed](https://www.rfc-editor.org/rfc/rfc7541#section-6.2.3) The POC implementation branch was generated by OpenAI Codex using GPT-5. It works and improves both cpu and bytes transferred in my benchmarks, but I am not a C++ programmer so I cannot vouch for the code. It is a POC/example only.", "url": "https://github.com/envoyproxy/envoy/issues/46584", "createdAt": "2026-08-07T22:45:58Z", "updatedAt": "2026-08-13T07:01:53Z", "timestamp": "2026-08-13T07:01:53Z", "metrics": { "reactions": 0, "comments": 3 }, "labels": [ "enhancement", "area/http" ], "author": "petedmarsh", "state": "open", "assignees": [] }, { "id": "github:envoyproxy/envoy:issue:46665", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "issue", "title": "cluster upstream_rq_timeout increments on requests that also complete successfully (rq_success == rq_total, rq_timeout independently non-zero)", "text": "### Summary For one specific upstream cluster, `envoy_cluster_upstream_rq_timeout` (and the equivalent `/clusters?format=json` admin stat `rq_timeout`) increments on requests that also complete successfully. On the same host, in the same admin snapshot, `rq_success` equals `rq_total` exactly, while `rq_timeout` is simultaneously non-zero — i.e. Envoy is counting some fraction of requests as *both* fully successful and timed out. This is not a rare edge case: on the affected cluster the ratio is currently 68-72% (`rq_timeout`/`rq_total`) and has persisted across proxy restarts, a route timeout config change, and an Envoy patch version bump, with the underlying application-level failure rate provably at zero throughout. ### Environment - Envoy `v1.35.10` (also reproduced on `v1.35.9`), via Contour `1.33.3` (`projectcontour/contour` chart) - Downstream: Gateway API `HTTPRoute`, no retry/hedge policy configured - Upstream: a single Kubernetes Service, 2 endpoints, plain HTTP/1.1 (no TLS), `StreamableHTTP`/JSON-over-HTTP traffic (not gRPC) - Traffic pattern: bursty/low-volume (roughly 1 request every few seconds), long-lived-ish client sessions, some requests carry `Connection: keep-alive` ### Evidence `GET /clusters?format=json` on the Contour-managed Envoy, same cluster, two hosts, one snapshot: ``` host .229: cx_connect_fail: (absent/0) cx_total: 226 rq_success: 290 rq_timeout: 199 rq_total: 290 host .87: cx_connect_fail: (absent/0) cx_total: 229 rq_success: 289 rq_timeout: 207 rq_total: 289 ``` `rq_success == rq_total` on both hosts. `rq_timeout` is not subtracted from either — it is tracked as an independent, non-exclusive counter. Cross-checked against the equivalent Prometheus stats (`envoy_cluster_upstream_rq_completed`, `envoy_cluster_upstream_rq_timeout`, `envoy_cluster_upstream_rq{envoy_response_code=...}`) over the same window: - `envoy_cluster_upstream_rq_completed` == `sum(envoy_cluster_upstream_rq)` by response code, exactly, at every sampled timestamp — every completed request has a normal, successful response code (`200`, mostly). No unaccounted/uncoded completions. - `envoy_cluster_upstream_cx_connect_fail`, `..._cx_connect_timeout`, `..._cx_pool_overflow`, `..._cx_idle_timeout`, `..._rq_per_try_timeout`, `..._rq_max_duration_reached`, `..._rq_rx_reset`, `..._rq_tx_reset` are all zero for this cluster throughout the observation window. - `envoy_cluster_health_check_*` does not exist for this cluster at all — no active health check is configured. - `histogram_quantile` on `envoy_cluster_upstream_rq_time_bucket` shows p50/p90/p99 well under any configured timeout (single-digit-to-low-double-digit milliseconds at the median; a small tail up to a few seconds). - No retry or hedge policy is configured on the route (confirmed via the live `config_dump`), so `rq_timeout` cannot be a per-try-timeout artifact of a retry we don't have. - The route in question does have an explicit `timeouts.request: 60s` (via Gateway API `HTTPRoute.spec.rules[].timeouts.request`, Contour v1.28.0+) — adding this reduced the *rate* of the effect by roughly 2-3x but did not eliminate it, and did not change the qualitative pattern (still `rq_success == rq_total` with `rq_timeout` ticking independently). ### What I've ruled out - Retries/hedging inflating `rq_timeout` via per-try semantics — none configured. - Connection pool exhaustion / stale pooled connections — all `cx_*` failure counters are zero. - A downstream idle/stream-idle timeout mismatch — `cx_idle_timeout` is zero, and Contour's `stream-idle-timeout` default (5m) is far looser than the actual p99 latency (low seconds). - Health-check-related eviction/probing — no health check exists on this cluster. - Actual application-level failures — response-code accounting balances exactly with zero 5xx growth throughout multi-hour windows, including windows where the timeout ratio itself was 60-90%. ### What I have NOT been able to determine The exact internal code path that increments `rq_timeout` without the request otherwise appearing to fail. My working hypothesis, unconfirmed, is a race in the router filter between the per-request timer callback and the upstream response-decode callback — i.e. the timer fires (and increments the stat) at approximately the same instant the real response is already committed and gets forwarded downstream anyway — but I have not been able to prove this without Envoy-internal tracing/debug logging beyond what `/stats` and `/clusters` expose. ### Reproduction I don't yet have a minimal standalone repro (e.g. a bare Envoy config + toy upstream) — this is observed on a real Contour-managed deployment with the traffic characteristics described above (low/bursty request volume, plain HTTP/1.1, JSON-RPC-over-HTTP style requests with `Connection: keep-alive`, no retries configured, an explicit but generous `route.timeout`). If a maintainer can suggest what to instrument or which debug log level would isolate the code path (e.g. `router` or `connection` debug components), I'm happy to reproduce with that logging enabled and report back. ### Ask - Does anything in the router filter legitimately increment `rq_timeout` for a request that ultimately succeeds (e.g. a timer/response race, or a stat that's intentionally non-exclusive with `rq_success`)? If this is expected/documented behavior I've missed, a pointer would be appreciated. - If not, any guidance on what to capture (debug log component/level, `/stats` more targeted) to pin the exact code path down further would let me turn this into a proper minimal repro.", "url": "https://github.com/envoyproxy/envoy/issues/46665", "createdAt": "2026-08-12T15:25:59Z", "updatedAt": "2026-08-12T15:33:19Z", "timestamp": "2026-08-12T15:33:19Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [], "author": "aleemshah-insignis", "state": "open", "assignees": [], "change": "updated" }, { "id": "github:envoyproxy/envoy:issue:46666", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "issue", "title": "health check probes blocked indefinitely when EDS initialFetchTimeout is 0s", "text": "*Title*: *health check probes blocked indefinitely when EDS initialFetchTimeout is 0s* *Description*: After I set EDS initialFetchTimeout as 0s, all envoy gateway conformance and e2e test cases failed in waiting for health check activity to appear. *Repro steps*: 1. set initialFetchTimeout: 0s 2. rerun all envoy gateway e2e test cases *Logs*: > === RUN TestE2E/BackendHealthCheckActiveHTTP/active_http > helpers.go:821: 2026-08-11T12:51:31.009924331Z: Conditions matched expectations > helpers.go:821: 2026-08-11T12:51:31.009977872Z: Route gateway-conformance-infra/http-with-health-check-active-http-pass Parents matched expectations > … > backend_health_check.go:112: 2026-08-11T12:52:40.144747982Z: cluster fail health check: new failure count: 2 (total: 2) > http.go:306: 2026-08-11T12:52:41.046201267Z: timeout while waiting after 60 attempts, 0/3 successes > > === RUN TestGatewayAPIConformance/BackendTLSPolicyConflictResolution/BackendTLSPolicies_targeting_the_same_Service_with_and_without_a_section_name/HTTP_request_sent_to_Service_using_the_BackendTLSPolicy_with_section_name_should_succeed > backendtlspolicy-conflict-resolution.go:130: 2026-08-11T12:52:47.817510589Z: Making GET request to host abc.example.com via http://172.18.0.200/backendtlspolicy-not-conflicted-with-section-name > http.go:325: 2026-08-11T12:52:47.828189571Z: Response expectation failed for request: {URL: {Scheme:http Opaque: User: Host:172.18.0.200 Path:/backendtlspolicy-not-conflicted-with-section-name Fragment: RawQuery: RawPath: RawFragment: ForceQuery:false OmitHost:false}, Host: abc.example.com, Protocol: HTTP, Method: GET, Headers: map[X-Echo-Set-Header:[]], UnfollowRedirect: false, ServerName: , ServerCertificate: , ClientCertificate: , ClientCertificateKey: } not ready yet: expected status code to be one of [200], got 400. CRes: &{400 -1 HTTP/1.1 map[Date:[Tue, 11 Aug 2026 12:52:47 GMT]] []} (after 1.732µs) >", "url": "https://github.com/envoyproxy/envoy/issues/46666", "createdAt": "2026-08-12T15:30:55Z", "updatedAt": "2026-08-12T15:30:55Z", "timestamp": "2026-08-12T15:30:55Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [ "bug", "triage" ], "author": "yuehaii", "state": "open", "assignees": [], "change": "updated" }, { "id": "github:envoyproxy/envoy:issue:46677", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "issue", "title": "reverse_tunnel: Implement proactive pings from the downstream_socket_interface", "text": "*Title*: reverse_tunnel: Implement proactive pings from the downstream_socket_interface *Description*: Currently the downstream_socket_interface does not proactive ping the upstream side using the RPING mechanism -> it only responds to pings this makes the downstream side invisible to reachability. Worse if the network falls through the downstream never detects it while the upstream thinks the connection is gone. This could have prevented issues like [this](https://github.com/envoyproxy/envoy/pull/46556). Expectation here is to implement http2 style ping and pong frames and have keepalive duration and timeout before the socket is upgraded to http2 for such detections from both ends.", "url": "https://github.com/envoyproxy/envoy/issues/46677", "createdAt": "2026-08-13T04:33:56Z", "updatedAt": "2026-08-13T08:22:42Z", "timestamp": "2026-08-13T08:22:42Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [ "enhancement", "no stalebot", "area/reverse_tunnels" ], "author": "aakugan", "state": "open", "assignees": [ "aakugan" ] }, { "id": "github:envoyproxy/envoy:issue:46678", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "issue", "title": "quic Support With OpenSSL", "text": "*Title*: *One line description* Support QUIC when Envoy is compiled with OpenSSL support enabled. *Description*: Desired Behaviour: Envoy when compiled with OpenSSL, should be able to serve quic based requests.", "url": "https://github.com/envoyproxy/envoy/issues/46678", "createdAt": "2026-08-13T06:32:03Z", "updatedAt": "2026-08-13T06:32:03Z", "timestamp": "2026-08-13T06:32:03Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [ "enhancement", "triage" ], "author": "Sukhdev841", "state": "open", "assignees": [] }, { "id": "github:envoyproxy/envoy:issue:46680", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "issue", "title": "Newer release available `dd_trace_cpp`: v2.2.0 (current: v2.1.1)", "text": "Package Name: dd_trace_cpp@2.1.1 Current Version: v2.1.1@2026-06-19 Available Version: v2.2.0@2026-08-12 Upstream releases: https://github.com/DataDog/dd-trace-cpp/releases", "url": "https://github.com/envoyproxy/envoy/issues/46680", "createdAt": "2026-08-13T08:33:29Z", "updatedAt": "2026-08-13T08:33:29Z", "timestamp": "2026-08-13T08:33:29Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [ "area/build", "no stalebot", "dependencies" ], "author": "github-actions[bot]", "state": "open", "assignees": [] }, { "id": "github:envoyproxy/envoy:issue:46681", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "issue", "title": "Newer release available `rules_shell`: v0.9.0 (current: v0.8.0)", "text": "Package Name: rules_shell@0.8.0 Current Version: v0.8.0@2026-04-15 Available Version: v0.9.0@2026-08-13 Upstream releases: https://github.com/bazelbuild/rules_shell/releases", "url": "https://github.com/envoyproxy/envoy/issues/46681", "createdAt": "2026-08-13T08:33:30Z", "updatedAt": "2026-08-13T08:33:30Z", "timestamp": "2026-08-13T08:33:30Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [ "area/build", "no stalebot", "dependencies" ], "author": "github-actions[bot]", "state": "open", "assignees": [] }, { "id": "github:envoyproxy/envoy:issue:6614", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "issue", "title": "Open Request Cost Aggregation (ORCA)", "text": "Today in Envoy, simple load balancing decisions can be made by taking into account local or global knowledge of a backend’s load, for example CPU. More sophisticated load balancing decisions are possible with application specific knowledge, e.g. queue depth, or by combining multiple metrics. This is useful for services that may be resource constrained along multiple dimensions (e.g. both CPU and memory may become bottlenecks, depending on the applied load and execution environment, it’s not possible to tell which upfront) and where these dimensions do not slot within predefined categories (e.g. the resource may be “number of free threads in a pool”, disk IOPS, etc.). https://docs.google.com/document/d/1NSnK3346BkBo1JUU3I9I5NYYnaJZQPt8_Z_XCBCI3uA/edit# provides a design proposal for an Open Request Cost Aggregation (ORCA) standard for conveying this information between proxies like Envoy and upstreams. We propose that this become a standard part of UDPA and supported by Envoy. The design document is in draft stage; from offline discussions I think the need for something like this is not very controversial, we can iterate on aspects of the design here.", "url": "https://github.com/envoyproxy/envoy/issues/6614", "createdAt": "2019-04-17T03:19:28Z", "updatedAt": "2026-08-12T18:03:46Z", "timestamp": "2026-08-12T18:03:46Z", "metrics": { "reactions": 13, "comments": 47 }, "labels": [ "enhancement", "help wanted" ], "author": "htuch", "state": "open", "assignees": [ "Mythra" ] }, { "id": "github:envoyproxy/envoy:issue:7468", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "issue", "title": "Hot restart lead to the abnormal exit of the new process", "text": "*Title*: *Hot restart lead to the abnormal exit of the new process* *Description*: During the hot restart, the new Envoy process will start a timer to send `sendParentTerminateRequest` messages after taking over the traffic. but if the parent process quits early, can lead to ` sendParentTerminateRequest ` trigger RELEASE_ASSERT send failure, this kind of behavior is unacceptable, because the new process has already started to take over the traffic. ``` void DrainManagerImpl::startParentShutdownSequence() { ASSERT(!parent_shutdown_timer_); parent_shutdown_timer_ = server_.dispatcher().createTimer([this]() -> void { // Shut down the parent now. It should have already been draining. ENVOY_LOG(info, \"shutting down parent after drain\"); server_.hotRestart().sendParentTerminateRequest(); }); parent_shutdown_timer_->enableTimer(std::chrono::duration_cast( server_.options().parentShutdownTime())); } void HotRestartingChild::sendParentTerminateRequest() { if (restart_epoch_ == 0 || parent_terminated_) { return; } HotRestartMessage wrapped_request; wrapped_request.mutable_request()->mutable_terminate(); sendHotRestartMessage(parent_address_, wrapped_request); parent_terminated_ = true; // Once setting parent_terminated_ == true, we can send no more hot restart RPCs, and therefore // receive no more responses, including stats. So, now safe to forget our stat transferral state. // // This destruction is actually important far beyond memory efficiency. The scope-based temporary // counter logic relies on the StatMerger getting destroyed once hot restart's stat merging is // all done. (See stat_merger.h for details). stat_merger_.reset(); } void HotRestartingBase::sendHotRestartMessage(sockaddr_un& address, const HotRestartMessage& proto) { ...... const int rc = sendmsg(my_domain_socket_, &message, 0); RELEASE_ASSERT(rc == static_cast(cur_chunk_size), fmt::format(\"hot restart sendmsg() failed: returned {}, errno {}\", rc, errno)); } RELEASE_ASSERT(fcntl(my_domain_socket_, F_SETFL, O_NONBLOCK) != -1, fmt::format(\"Set domain socket nonblocking failed, errno = {}\", errno)); } ``` I think need to refactor ` sendHotRestartMessage `, send the results of the return, can be treated with the result of sending calls, rather than a unified RELEASE_ASSERT to deal with.", "url": "https://github.com/envoyproxy/envoy/issues/7468", "createdAt": "2019-07-04T07:00:40Z", "updatedAt": "2026-08-13T09:37:09Z", "timestamp": "2026-08-13T09:37:09Z", "metrics": { "reactions": 2, "comments": 4 }, "labels": [ "question" ], "author": "zyfjeff", "state": "closed", "assignees": [] }, { "id": "github:envoyproxy/envoy:pull_request:42890", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "[WIP] bazel: Switch to bzlmod", "url": "https://github.com/envoyproxy/envoy/pull/42890", "createdAt": "2026-01-07T13:47:23Z", "updatedAt": "2026-08-13T11:32:30Z", "timestamp": "2026-08-13T11:32:30Z", "metrics": { "reactions": 0, "comments": 5 }, "labels": [ "no stalebot", "api", "v2-freeze", "deps", "workflows:untested" ], "author": "phlax", "state": "open", "assignees": [ "RyanTheOptimist" ] }, { "id": "github:envoyproxy/envoy:pull_request:43255", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "[WIP] bazel: Add compatibility stubs for bzlmod", "text": "this provides some of the compatibility required for bzlmod, without breaking workspace mode will follow up to fully enable bzlmod (as non-default in subsequent pr)", "url": "https://github.com/envoyproxy/envoy/pull/43255", "createdAt": "2026-02-01T01:15:57Z", "updatedAt": "2026-08-13T15:10:28Z", "timestamp": "2026-08-13T15:10:28Z", "metrics": { "reactions": 0, "comments": 3 }, "labels": [ "no stalebot", "deps", "ai:assisted" ], "author": "phlax", "state": "open", "assignees": [ "RyanTheOptimist" ] }, { "id": "github:envoyproxy/envoy:pull_request:43355", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "Queue policy extension", "text": "As agreed in https://github.com/envoyproxy/envoy/pull/28982 we first introduce extension point for queue policy to support more algorithms in future (e.g. codel, adaptive lifo). This PR introduces fifo queue extension currently used in core code. Commit Message: Additional Description: Risk Level: Testing: Docs Changes: Release Notes: Platform Specific Features: [Optional Runtime guard:] [Optional Fixes #Issue] [Optional Fixes commit #PR or SHA] [Optional [API Considerations](https://github.com/envoyproxy/envoy/blob/main/api/review_checklist.md):]", "url": "https://github.com/envoyproxy/envoy/pull/43355", "createdAt": "2026-02-06T14:35:45Z", "updatedAt": "2026-08-12T14:18:42Z", "timestamp": "2026-08-12T14:18:42Z", "metrics": { "reactions": 0, "comments": 19 }, "labels": [], "author": "nezdolik", "state": "open", "assignees": [ "tonya11en", "yanavlasov", "markdroth", "balrawi-figma" ], "change": "updated" }, { "id": "github:envoyproxy/envoy:pull_request:43771", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "Manage on-call rotation and ical generation in code", "text": "Commit Message: Manage on-call rotation and ical generation in code Additional Description: Our dependency on opsgenie appears to have run its course - our notifications keep drifting out of sync, the calendar isn't working very well, and we don't have enough seats to even have the scheduling be correct. These scripts should make it fairly easy to manage the oncall rotation through code, without need for external accounts. The generated ical calendar is required to be up-to-date by a `py_test` target that will fail if changes are not kept synchronized, keeping us from accidentally drifting out of sync. Removing people from the rotation should be cleaner with this script, as it makes a concerted effort to minimize schedule disruption - the goal is to keep schedule changes at least 2 months in the future (provided someone is willing to volunteer to substitute for one shift for a removed person - if not, there is a `dirty` option to allow schedules to be disrupted.) followups TODO: - [ ] update `GOVERNANCE.md` (search \"opsgenie\") to instead reference the new ical. - [ ] Update the google calendar to source from the new ical. - [ ] Update `tools/repo/notify.py` to source from the helper library. Risk Level: None, doesn't change anything currently active. Testing: Manually validated adding and each of the variations of removing, ensuring that the ical file was updated appropriately in each case. Docs Changes: Just the included README.md. Release Notes: n/a Platform Specific Features: n/a", "url": "https://github.com/envoyproxy/envoy/pull/43771", "createdAt": "2026-03-04T20:18:05Z", "updatedAt": "2026-08-13T08:17:46Z", "timestamp": "2026-08-13T08:17:46Z", "metrics": { "reactions": 0, "comments": 13 }, "labels": [ "no stalebot", "waiting" ], "author": "ravenblackx", "state": "open", "assignees": [ "phlax" ] }, { "id": "github:envoyproxy/envoy:pull_request:45073", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "c-ares: make qcache_max_ttl configurable", "text": "Commit Message: c-ares: make qcache_max_ttl configurable Additional Description: expose the qcache_max_ttl setting and share DNSResolver if cares config is the same so the qcache can be shared. runtime guard \"envoy.restart_features.shared_cares_dns_resolver\" is set to true by default to enable sharing DNSResolver if cares config of the clusters are the same. Set to false to disable this behavior. AI is used to generate the tests and write some of the comment but I did review and tune/modify all the tests added. All other code are hand written. Risk Level: Low Testing: unit test and manual test using tcpdump to verify multiple clusters with the same host (different port) only generate 1 dns lookup most of the time. Docs Changes: None Release Notes: Added qcache_max_ttl field to CaresDnsResolverConfig Platform Specific Features: None [Optional Runtime guard:] \"envoy.restart_features.shared_cares_dns_resolver\" is set to true by default to enable sharing DNSResolver if cares config of the clusters are the same. Set to false to disable this behavior.", "url": "https://github.com/envoyproxy/envoy/pull/45073", "createdAt": "2026-05-14T17:09:02Z", "updatedAt": "2026-08-13T13:54:26Z", "timestamp": "2026-08-13T13:54:26Z", "metrics": { "reactions": 0, "comments": 15 }, "labels": [], "author": "andy-fong", "state": "closed", "assignees": [ "yanavlasov", "markdroth" ] }, { "id": "github:envoyproxy/envoy:pull_request:45674", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "hot restart: propagate programmatic stat tags across restart", "text": "**Commit Message:** hot restart: propagate programmatic stat tags across restart **Additional Description:** Stats created with programmatic tags (via `Scope::*FromStatNameWithTags` / the tag-aware `*FromTaggedName` API) embed their tag *values* into the flat stat name while keeping a clean `tagExtractedName` and a set of tags. This works on a fresh process, but breaks across a hot restart: - The parent serializes each counter/gauge to the child as **name string → value** only (`HotRestartingParent::Internal::exportStatsToChild`); `tags()` / `tagExtractedName()` are dropped. - The child's `StatMerger::mergeCounters` re-creates the stat from the name alone, which runs only regex tag extraction. With no matching `stats_tags` regex, the merged stat gets **empty tags** and `tagExtractedName == the full mangled name`. - That no-tags stat is created **before** the child's own code first touches the stat, so it wins the central-cache slot. The later tagged creation returns the already-mangled stat (stats are immutable post-creation). The tag values end up baked into the metric name with empty labels (e.g. as exported to Prometheus). This is the gap behind the long-standing `// TODO(snowp): Propagate tag values during hot restarts` in `stat_merger.cc`. Regex-extracted tags survive only because extraction re-derives them from the name; programmatic tags have nothing to re-derive from. This change actually propagates the tags: - `hot_restart.proto`: new `TaggedMetric` (tag-extracted name + repeated `Tag`) and `counter_tags` / `gauge_tags` maps on `Reply.Stats`. - The parent emits an entry **only for tags the child could not re-derive from the name**: it re-runs the store's `TagProducer` on the flat name and skips the stat when extraction reproduces the stored tags (the common case — including all default tag regexes). The stats transfer payload is therefore unchanged except for stats that actually carry programmatic tags. A nullable `Store::tagProducer()` accessor (default `nullptr`; only `ThreadLocalStoreImpl` overrides) supports the comparison. - The child decodes the metadata and `StatMerger` re-creates the stat with the original tags via new `Scope::counterFromMergedStatName` / `gaugeFromMergedStatName`. Following #45146 these have non-virtual-breaking defaults that delegate to the tag-aware `counterFromTaggedName` / `gaugeFromTaggedName` (which retain the metadata on tag-aware scopes and `IsolatedStoreImpl`); the legacy `ThreadLocalStore` `ScopeImpl` — which intentionally drops tag metadata on the `*FromTaggedName` path because it cannot compose tag-extracted names with its prefix in general — overrides them to honor the components, which arrive fully resolved. The full name is still reconstructed via `DynamicContext` (dynamic spans preserved), so the cache key matches the stat the child independently creates — the fix removes the first-write-wins poisoning rather than working around it. **Risk Level:** Medium — changes stats labels after a hot restart for tag-bearing stats. Runtime guarded. **Testing:** New tests: `stat_merger_test` (`ProgrammaticTagsSurviveMerge`, `ProgrammaticGaugeTagsSurviveMerge`, `ProgrammaticTagsLostWithoutMetadata` pinning the pre-fix symptom), `hot_restarting_parent_test` (`ExportsTagMetadataOnlyWhenNotRederivable`, `TagMetadataAppliedToMergedStats` end-to-end, `TagMetadataIgnoredWhenRuntimeFlagDisabled`), and `thread_local_store_test` (`MergedStatNameHonorsSuppliedTags` on both the legacy and tag-aware scopes). Built/run via RBE. **Docs Changes:** N/A **Release Notes:** Added (`changelogs/current/bug_fixes/stats__hot-restart-propagate-programmatic-stat-tags.rst`). **Runtime guard:** `envoy.reloadable_features.hot_restart_propagate_stat_tags` (revert to legacy name-derived behavior).", "url": "https://github.com/envoyproxy/envoy/pull/45674", "createdAt": "2026-06-16T23:12:06Z", "updatedAt": "2026-08-13T15:26:38Z", "timestamp": "2026-08-13T15:26:38Z", "metrics": { "reactions": 0, "comments": 14 }, "labels": [], "author": "bpalermo", "state": "open", "assignees": [ "wbpcode", "paul-r-gall" ] }, { "id": "github:envoyproxy/envoy:pull_request:45882", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "hot_restart: fix integer overflow in IPC message length handling", "text": "Description: The hot restart IPC protocol reads a uint64_t message length from the first 8 bytes of an incoming datagram and uses it to compute the required receive buffer size. When expected_proto_length_ is close to UINT64_MAX, adding sizeof(uint64_t) may wrap around due to unsigned integer overflow, producing an invalid buffer size value. Add an explicit overflow check before resizing the receive buffer, matching existing overflow-detection patterns used elsewhere in the Envoy codebase. Also adds unit tests covering overflow edge cases and normal message processing. Risk Level: Low Testing: * Added unit tests for UINT64_MAX * Added unit tests for UINT64_MAX - 7 * Added unit tests for normal-length messages Docs Changes: N/A Release Notes: Included Fixes #45872", "url": "https://github.com/envoyproxy/envoy/pull/45882", "createdAt": "2026-06-29T14:33:54Z", "updatedAt": "2026-08-12T23:04:13Z", "timestamp": "2026-08-12T23:04:13Z", "metrics": { "reactions": 0, "comments": 5 }, "labels": [ "stale", "waiting" ], "author": "ghaithabdulreda", "state": "closed", "assignees": [ "yanavlasov" ] }, { "id": "github:envoyproxy/envoy:pull_request:45914", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "stats: migrate rds/scope rds to use new stats API", "text": "Commit Message: stats: migrate rds/scope rds to use new stats API Additional Description: Parts of #20289. This migrate the previous stats creation to use new tags-friendly API. But note, before we merge https://github.com/envoyproxy/envoy/pull/45846 and enable it explicitly. This won't bring any changes to the final behavior because the legacy mode will ignore the provided tags but only use the flat name. Risk Level: low. Testing: unit. Docs Changes: n/a. Release Notes: n/a. Platform Specific Features: n/a.", "url": "https://github.com/envoyproxy/envoy/pull/45914", "createdAt": "2026-07-01T13:31:13Z", "updatedAt": "2026-08-12T16:17:37Z", "timestamp": "2026-08-12T16:17:37Z", "metrics": { "reactions": 0, "comments": 4 }, "labels": [ "stale" ], "author": "wbpcode", "state": "open", "assignees": [ "ggreenway", "paul-r-gall" ], "change": "updated" }, { "id": "github:envoyproxy/envoy:pull_request:45951", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "Add max cap to guard against malicious number token input", "text": "For Number token, there are two cases, this cap is only applicable to the case 2 (1) Huge Number token that arrive complete with their terminator in the same chunk: This is not subject to attack vector here, hence the limit in this PR here is not applicable, as it is bounded by the max_body_bytes limit in the upper layer (2) Huge Number token is split and sent via many small data chunks by attacker, when NUMBER token straddles a chunk boundary, it will cause Wuffs to rewind its ead cursor and the cursor to save the unread bytes in pending_bytes_. Thus we need to cap the pending_bytes here. Tests have been added. https://github.com/envoyproxy/envoy/issues/44681", "url": "https://github.com/envoyproxy/envoy/pull/45951", "timestamp": "2026-08-12T12:56:02Z", "metrics": { "reactions": 0, "comments": 2 }, "labels": [], "author": "tyxia", "assignees": [], "change": "new" }, { "id": "github:envoyproxy/envoy:pull_request:45983", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "stats: migrate almost all HTTP to new API", "text": "Commit Message: stats: migrate almost all HTTP to new API Additional Description: Parts of https://github.com/envoyproxy/envoy/issues/20289. This migrate the previous stats creation to use new tags-friendly API. But note, before we merge https://github.com/envoyproxy/envoy/pull/45846 and enable it explicitly. This won't bring any changes to the final behavior because the legacy mode will ignore the provided tags but only use the flat name. Risk Level: mid. Changed too much code. Orz. Testing: unit. Docs Changes: n/a. Release Notes: n/a. Platform Specific Features: n/a.", "url": "https://github.com/envoyproxy/envoy/pull/45983", "createdAt": "2026-07-05T13:02:46Z", "updatedAt": "2026-08-12T16:17:39Z", "timestamp": "2026-08-12T16:17:39Z", "metrics": { "reactions": 0, "comments": 4 }, "labels": [ "stale" ], "author": "wbpcode", "state": "closed", "assignees": [ "yanavlasov" ], "change": "updated" }, { "id": "github:envoyproxy/envoy:pull_request:46006", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "test: fix flaky xds_failover StartupPrimaryNotResponding for GoogleGrpc TRANSIENT_FAILURE", "text": "`XdsFailoverAdsIntegrationTest.StartupPrimaryNotResponding/15` (IPv6, GoogleGrpc, UnifiedDelta) fails intermittently under ASAN due to a race between gRPC's real-time channel backoff and Envoy's simulated-time retry timer. ## Root cause After the first `primaryConnectionFailure()` closes the TCP connection, the gRPC channel enters `TRANSIENT_FAILURE` with a ~1s real-time backoff. `waitForPrimaryXdsRetryTimer()` advances **simulated** time, firing Envoy's retry timer before that real-time backoff expires. The gRPC library immediately rejects the `establishNewStream()` attempt (no TCP connection made), which counts as the 2nd consecutive failure and triggers failover. The test's second `primaryConnectionFailure()` then waits 30s (ASAN `DefaultTimeout`) for a primary TCP connection that never arrives — Envoy has already switched to failover — hitting the `RELEASE_ASSERT`. This race is timing-sensitive: for IPv4 the gRPC library fast-retries before `onEstablishmentFailure` fires (channel stays in `CONNECTING`), so the race doesn't manifest there. ## Fix In `StartupPrimaryNotResponding`, before the second `primaryConnectionFailure()` call, poll (real-time only, **no** simulated clock advancement) for `cds.update_failure ≥ 2` within `200×TIMEOUT_FACTOR` ms. If the counter reaches 2, the 2nd failure already occurred via `TRANSIENT_FAILURE` and the explicit TCP-close step is skipped: ```cpp bool second_failure_via_transient_failure = false; if (clientType() == Grpc::ClientType::GoogleGrpc) { const auto deadline = absl::Now() + absl::Milliseconds(200 * TIMEOUT_FACTOR); constexpr absl::Duration kPollInterval = absl::Milliseconds(5); while (absl::Now() < deadline) { const auto counter = TestUtility::findCounter( test_server_->statStore(), \"cluster_manager.cds.update_failure\"); if (counter != nullptr && counter->value() >= 2) { second_failure_via_transient_failure = true; break; } absl::SleepFor(kPollInterval); } } if (!second_failure_via_transient_failure) { primaryConnectionFailure(); ASSERT_TRUE(xds_connection_->waitForDisconnect()); } ``` Polling uses real time (not `advanceTimeWait`) to avoid firing additional simulated timers that could interfere with test state. The `200×TIMEOUT_FACTOR` window is well above the typical <60ms propagation latency for the gRPC completion queue → Envoy main thread path. ## Files changed - **`test/extensions/config_subscription/grpc/xds_failover_integration_test.cc`** — TRANSIENT_FAILURE detection + `absl/time` includes - **`test/extensions/config_subscription/grpc/BUILD`** — added `@abseil-cpp//absl/time` dep", "url": "https://github.com/envoyproxy/envoy/pull/46006", "createdAt": "2026-07-06T23:11:54Z", "updatedAt": "2026-08-13T04:32:57Z", "timestamp": "2026-08-13T04:32:57Z", "metrics": { "reactions": 0, "comments": 3 }, "labels": [ "stale" ], "author": "Copilot", "state": "closed", "assignees": [ "yanavlasov", "Copilot" ] }, { "id": "github:envoyproxy/envoy:pull_request:46113", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "build(deps): bump mypy from 1.20.2 to 2.3.0 in /mobile/tools/python", "text": "Bumps [mypy](https://github.com/python/mypy) from 1.20.2 to 2.3.0.
Changelog

Sourced from mypy's changelog.

Mypy Release Notes

Next Release

Packaging changes

Mypy 2.3

We've just uploaded mypy 2.3.0 to the Python Package Index (PyPI). Mypy is a static type checker for Python. This release includes new features, performance improvements and bug fixes. You can install it as follows:

python3 -m pip install -U mypy

You can read the full documentation for this release on Read the Docs.

The Upcoming Switch to the New Native Parser

We are planning to enable the new native parser (--native-parser) by default soon. We recommend that you test the native parser in your projects and report any issues in the mypy issue tracker.

Mypyc Free-threading Memory Safety

Free-threaded Python builds that don't have the GIL require additional synchronization primitives or lock-free algorithms to ensure memory safety when there are race conditions (for example, when a thread reads a list item while another thread writes the same list item concurrently). This release greatly improves memory safety of free threading.

List operations are now memory-safe on free threaded Python builds, even in the presence of race conditions. This has some performance cost. For list-heavy workloads, using librt.vecs.vec instead of list is often significantly faster, but note that vec is not (and likely won't be) fully memory safe, and the user is expected to avoid race conditions. The newly introduced librt.threading.Lock helps with this. Using variable-length tuples can also be more efficient than lists, since tuples are immutable and don't require expensive synchronization to ensure memory safety.

Instance attribute access is also (mostly) memory safe now on free-threaded builds in the presence of race conditions. We are planning to fix the remaining unsafe cases in a future release.

Full list of changes:

  • Make attribute access memory safe on free-threaded builds (Jukka Lehtosalo, PR 21705)
  • Fix unsafe borrowing of instance attributes with free-threading (Jukka Lehtosalo, PR 21688)
  • Make list get/set item more memory safe on free-threaded builds (Jukka Lehtosalo, PR 21683)
  • Don't borrow list items on free-threaded builds (Jukka Lehtosalo, PR 21679)
  • Make multiple assignment from list memory-safe on free-threaded builds (Jukka Lehtosalo, PR 21684)

... (truncated)

Commits
  • 8aabf84 Drop +dev from version
  • 4d8ad2a Update changelog for 2.3 release (#21728)
  • 2c21546 [mypyc] Update documentation of race conditions under free threading (#21726)
  • a9f62a3 [mypyc] Make attribute access memory safe on free-threaded builds (#21705)
  • 0faa413 Use PYODIDE environment variable for Emscripten cross-compilation detection...
  • 3d75cdb [mypyc] Borrow final attributes more aggressively (#21702)
  • 24c237d [mypyc] Improve documentation of Final (#21713)
  • b5be217 [mypyc] Update free threading Python compatibility docs (#21711)
  • cbcb51a Narrow for frozendict membership check (#21709)
  • af2bc0f Sync typeshed (#21707)
  • Additional commits viewable in compare view

[![Dependabot compatibility score](https://dependabot-badges.githubapp.com/badges/compatibility_score?dependency-name=mypy&package-manager=pip&previous-version=1.20.2&new-version=2.3.0)](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) ---
Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot show ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
", "url": "https://github.com/envoyproxy/envoy/pull/46113", "createdAt": "2026-07-14T06:06:32Z", "updatedAt": "2026-08-13T08:27:31Z", "timestamp": "2026-08-13T08:27:31Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [ "stale", "dependencies", "python" ], "author": "dependabot[bot]", "state": "open", "assignees": [] }, { "id": "github:envoyproxy/envoy:pull_request:46138", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "add ratelimit descriptor extension to use jwt claims as descriptors", "text": "Commit Message: add ratelimit descriptor extension to use jwt claims as descriptors Additional Description: Adds a new rate limit descriptor extension that extracts jwt claims and uses it to rate limit. This is useful in cases where the actual JWT validation is done by the application but we want to apply rate limits based on jwt claims Risk Level: Low Testing: Docs Changes: Release Notes:", "url": "https://github.com/envoyproxy/envoy/pull/46138", "createdAt": "2026-07-15T06:07:55Z", "updatedAt": "2026-08-13T13:34:46Z", "timestamp": "2026-08-13T13:34:46Z", "metrics": { "reactions": 1, "comments": 11 }, "labels": [ "api" ], "author": "ramaraochavali", "state": "open", "assignees": [ "adisuissa" ] }, { "id": "github:envoyproxy/envoy:pull_request:46300", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "AI Protocol Parser: add ParserConfig for the wuffs JSON parser", "text": "Introduces ParserConfig to bound the parsing and capture and control streaming JSON field extraction on top of WuffsJsonCursor. The use of ParserConfig are shown in the test handler, agentic(MCP/A2A) and LLM(openAI/Gemini) handler will be implemented in the next PRs. Capture limitation, (TODO define good defaults) - max_body_bytes: pre-feed cap on raw bytes entering the cursor. - max_per_scalar_bytes: per-string-value cap. Over-budget values are rejected — dropped entirely - max_total_scalar_capture_bytes: body-wide retention budget across all captured values. A value that would overflow the total is dropped without consuming budget, so later smaller values still fit. - max_element_capture_bytes: per container byte-range capture. Two capture modes 1. Spec-based extraction (`extract_fields`) — the caller declares which fields to extract as pattern paths (\"model\", \"params._meta.traceparent\", \"messages[].role\", \"tools[].function.name\"). 2. Capture-all mode (`capture_all_scalars`) — captures every scalar value (strings, numbers, booleans, nulls) at every depth to maxDepth Clean-up and Clarification - clean up and polish the code comment - buildIndex/PatternPath and path tracking are not needed anymore, replaced by matchesPatternPath - number token is also bounded by max_body_bytes introduced in this PR. https://github.com/envoyproxy/envoy/issues/44681", "url": "https://github.com/envoyproxy/envoy/pull/46300", "createdAt": "2026-07-22T02:26:22Z", "updatedAt": "2026-08-12T16:41:27Z", "timestamp": "2026-08-12T16:41:27Z", "metrics": { "reactions": 0, "comments": 3 }, "labels": [], "author": "tyxia", "state": "open", "assignees": [ "penguingao", "yanavlasov", "agrawroh" ] }, { "id": "github:envoyproxy/envoy:pull_request:46308", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "composite: fail over to the next sub-cluster when a sub-cluster has no hosts", "text": "## Commit Message composite: fail over to the next sub-cluster when a sub-cluster has no hosts The composite cluster failed a request with 503 no_healthy_upstream when the sub-cluster mapped to the current attempt had no host available, for example because DNS resolution returned an empty endpoint list or because all of its hosts had been ejected. Host selection now advances to the following sub-clusters in the configured list within the same attempt, and only fails when none of them can provide a host. Guarded by `envoy.reloadable_features.composite_cluster_skip_clusters_without_hosts`. ## Additional Description ### Documented behavior vs. actual behavior The `composite_cluster` [docs](https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/upstream/composite_cluster) stated: > *\"If a selected sub-cluster has no healthy hosts available, the request will fail according to that sub-cluster's load balancing behavior, **potentially triggering another retry attempt if configured**.\"* In practice that retry path was unreachable: `no_healthy_upstream` is a routing-level rejection raised before any upstream connection attempt, and no `retry_on` condition covers it. A composite cluster whose first sub-cluster had zero endpoints failed with `503 no_healthy_upstream` regardless of the retry policy, so per-request failover did not work at all in that scenario. ### Change from the previous revision of this PR The first revision of this PR added a core `no-healthy-upstream` retry condition (`RETRY_ON_NO_HEALTHY_UPSTREAM`) plus a hook in `Filter::createConnPoolOrHandleFailure()`. Per review feedback from @wbpcode and @agrawroh, that a core feature serving one extension is the wrong layer, and that the composite cluster should pick a sub-cluster that has healthy hosts itself. The previous approach has been fully reverted and the fix now lives entirely in the extension. Reverted back to `main`: `envoy/router/router.h`, `source/common/http/headers.h`, `source/common/router/retry_state_impl.{h,cc}`, `source/common/router/router.cc`, `test/common/router/{router_test,retry_state_impl_test}.cc`, `test/mocks/router/mocks.{h,cc}`, `api/envoy/config/route/v3/route_components.proto`, `docs/root/configuration/http/http_filters/router_filter.rst`. ### Fix `CompositeClusterLoadBalancer::chooseHost()` still maps the attempt count to a starting cluster index, but host selection now runs through a new `selectHostWithFailover()` helper that walks forward from that index: * A sub-cluster is skipped when it is not present in the cluster manager, or when its load balancer returns no host. * Selection returns immediately when a host is selected, or when the sub-cluster started asynchronous host selection (`HostSelectionResponse::cancelable` set), so an in-flight async selection is not abandoned or duplicated. * When no sub-cluster can provide a host, the `details` and `failure_status` of the last sub-cluster tried are propagated, so the resulting local reply keeps the same diagnostics as before. Availability is determined by asking the sub-cluster's load balancer rather than by inspecting its priority set, so nested composite/aggregate sub-clusters, `CLUSTER_PROVIDED` sub-clusters, panic mode and override-host behavior all keep working. When a sub-cluster can serve the attempt, its load balancer is the only one invoked, so there are no wasted host selections on the happy path. ### Behavior notes * Selection remains driven by the attempt count: an attempt that failed over to a later sub-cluster does not shift the mapping of subsequent attempts. With `[primary, secondary, fallback]` and an empty `primary`, attempt 1 uses `secondary` and attempt 2 also maps to `secondary`. This is documented in the arch overview. If reviewers prefer that a failover also advance the following attempts, that can be done by recording the used index in filter state — happy to add it here or as a follow-up. * `peekAnotherHost()` and `selectExistingConnection()` keep the plain attempt mapping. Every in-tree `selectExistingConnection()` implementation returns `nullopt`, so there is no practical mismatch, and prefetching does not need the failover. ### Minimal reproduction A minimal Docker Compose reproduction of the original bug is available at: https://github.com/JonSchaeffer/playground/tree/main/envoy/composite-bug-minimal-repro ## Risk Level Low — the change is scoped to the composite cluster extension, and it is behind a reloadable runtime guard. ## Testing * Unit tests in `test/extensions/clusters/composite/cluster_test.cc`: failover when the selected sub-cluster has no host, failover when the selected sub-cluster is missing from the cluster manager, no host plus preserved failure details when no sub-cluster can serve the request, asynchronous host selection returned without trying other sub-clusters, and legacy behavior with the runtime guard disabled. * Integration tests in `test/extensions/clusters/composite/cluster_integration_test.cc`: failover with `num_retries: 0` (proving no retry is involved), failover across two consecutive sub-clusters without endpoints, `503` when no sub-cluster has endpoints, and `503` with the runtime guard disabled. The two `no-healthy-upstream` retry tests from the previous revision were removed. * Format and spelling checks: `bazel run //tools/code_format:check_format` and `bazel run //tools/spelling:check_spelling_pedantic` both pass. ## Docs Changes * `docs/root/intro/arch_overview/upstream/composite_cluster.rst`: new \"Hosts availability\" section, updated the sub-cluster health / deterministic routing considerations, and documented the runtime guard and the attempt-progression caveat. * `api/envoy/extensions/clusters/composite/v3/cluster.proto`: comment-only update describing the failover. No field or type changes. ## Release Notes `changelogs/current/bug_fixes/composite_cluster__skip-clusters-without-hosts.rst`. ## Runtime guard `envoy.reloadable_features.composite_cluster_skip_clusters_without_hosts` (enabled by default). Setting it to `false` restores the previous behavior of failing the attempt when the sub-cluster mapped to that attempt has no host available. --- > **Note:** This PR was developed with AI assistance (Claude). The author has reviewed and > understands all changes.", "url": "https://github.com/envoyproxy/envoy/pull/46308", "createdAt": "2026-07-22T12:31:41Z", "updatedAt": "2026-08-13T13:51:19Z", "timestamp": "2026-08-13T13:51:19Z", "metrics": { "reactions": 0, "comments": 9 }, "labels": [ "api" ], "author": "JonSchaeffer", "state": "open", "assignees": [ "agrawroh", "wbpcode" ] }, { "id": "github:envoyproxy/envoy:pull_request:46318", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "ext_proc: adding direct mode_override support", "text": "This is a follow up implementation for https://github.com/envoyproxy/envoy/pull/46315", "url": "https://github.com/envoyproxy/envoy/pull/46318", "createdAt": "2026-07-22T21:30:10Z", "updatedAt": "2026-08-13T17:31:37Z", "timestamp": "2026-08-13T17:31:37Z", "metrics": { "reactions": 0, "comments": 11 }, "labels": [ "api" ], "author": "yanjunxiang-google", "state": "open", "assignees": [ "stevenzzzz", "adisuissa", "yanavlasov", "rshriram", "tyxia" ] }, { "id": "github:envoyproxy/envoy:pull_request:46358", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "redis: fix use-after-free and connection leak on cluster removal", "text": "Commit Message: redis: fix use-after-free and connection leak on cluster removal Additional Description: Each discovery client holds a shared_ptr back to the `RedisDiscoverySession` (as its client `Config`), so `~RedisCluster()` dropping its reference does not destroy the session while a discovery connection is open — the common steady state. The session then outlives the cluster with its resolve timer still armed, and the next fire dereferences the destroyed cluster. In-flight hostname resolutions (`CLUSTER SLOTS` entries that return hostnames, e.g. AWS ElastiCache) and zone-discovery `INFO` requests were never cancelled either. Cluster teardown now explicitly shuts the session down: it cancels the in-flight slot request, zone-discovery `INFO` requests and hostname resolutions (their `resolve()` handles are now tracked), disables the resolve timer, and closes the discovery connections (previously leaked). A session-owned `shutdown_` flag gates the entry points that can still reach the surviving session. All discovery work runs on the main thread, so the `is_destroying_` atomic is removed. Risk Level: low Testing: new unit tests (cluster destruction with held client config references, in-flight hostname resolution cancellation, in-flight zone-discovery `INFO` cancellation); existing redis_cluster_test suite green Docs Changes: n/a Release Notes: changelogs/current/bug_fixes/redis_proxy__cluster-destruction-use-after-free.rst Platform Specific Features: n/a", "url": "https://github.com/envoyproxy/envoy/pull/46358", "createdAt": "2026-07-23T23:38:36Z", "updatedAt": "2026-08-13T11:02:47Z", "timestamp": "2026-08-13T11:02:47Z", "metrics": { "reactions": 0, "comments": 3 }, "labels": [], "author": "bellatoris", "state": "open", "assignees": [ "nezdolik" ] }, { "id": "github:envoyproxy/envoy:pull_request:46460", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "[bp/v1.36] dfp: fix a bug when cluster is removed before async lb be completed (#45064)", "text": "Commit Message: dfp: fix a bug when cluster is removed before async lb be completed Additional Description: In the previous implementation, both the router/DFP cluster may access invalid pointer if a cluster is removed then the request is pending and waiting the async load balancing result. Risk Level: Testing: Docs Changes: Release Notes: Platform Specific Features: [Optional Runtime guard:] [Optional Fixes #Issue] [Optional Fixes commit #PR or SHA] [Optional Deprecated:]", "url": "https://github.com/envoyproxy/envoy/pull/46460", "createdAt": "2026-07-30T13:49:45Z", "updatedAt": "2026-08-12T18:45:55Z", "timestamp": "2026-08-12T18:45:55Z", "metrics": { "reactions": 0, "comments": 4 }, "labels": [], "author": "wbpcode", "state": "closed", "assignees": [ "phlax", "RyanTheOptimist" ] }, { "id": "github:envoyproxy/envoy:pull_request:46461", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "[bp/v1.37] dfp: fix a bug when cluster is removed before async lb be completed (#45064)", "text": "Commit Message: dfp: fix a bug when cluster is removed before async lb be completed Additional Description: In the previous implementation, both the router/DFP cluster may access invalid pointer if a cluster is removed then the request is pending and waiting the async load balancing result. Risk Level: Testing: Docs Changes: Release Notes: Platform Specific Features: [Optional Runtime guard:] [Optional Fixes #Issue] [Optional Fixes commit #PR or SHA] [Optional Deprecated:]", "url": "https://github.com/envoyproxy/envoy/pull/46461", "createdAt": "2026-07-30T13:51:20Z", "updatedAt": "2026-08-12T18:45:37Z", "timestamp": "2026-08-12T18:45:37Z", "metrics": { "reactions": 0, "comments": 3 }, "labels": [], "author": "wbpcode", "state": "closed", "assignees": [ "phlax", "RyanTheOptimist" ] }, { "id": "github:envoyproxy/envoy:pull_request:46479", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "tls: allow multiple TLS certificates in the upstream when using a custom TLS certificate selector", "text": "Commit Message: Allow multiple TLS certificates in the upstream tls context when using a custom TLS certificate selector. The single cert check is kept if one is not defined. Additional Description: We are working on an internal TLS certificate selector for UpstreamTLSContext that can select between multiple client certificate. By default only one is allowed, so we need a way to allow multiple once our custom TLS certificate selector is enabled. Risk Level: Medium Testing: Added unit tests, tested manually to check it works with our custom cert selector. Docs Changes: Added documentation in the API proto for `tls_certificates` to indicate multiple certs are allowed in a client context when a custom TLS certificate selector is used. Release Notes: Added a release note under new features. Platform Specific Features: N/A", "url": "https://github.com/envoyproxy/envoy/pull/46479", "createdAt": "2026-07-31T05:45:00Z", "updatedAt": "2026-08-12T17:33:01Z", "timestamp": "2026-08-12T17:33:01Z", "metrics": { "reactions": 0, "comments": 6 }, "labels": [], "author": "Berro321", "state": "open", "assignees": [ "adisuissa", "botengyao" ] }, { "id": "github:envoyproxy/envoy:pull_request:46496", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "http: add support for the QUERY method (RFC 10008)", "text": "## Commit Message Adds support for the `QUERY` request method registered by `RFC 10008`. Before this change, an `HTTP/1` request using the `QUERY` method was rejected by the codec with a `400` and `HPE_INVALID_METHOD`, because the method token is matched against a fixed list of known methods that predates the RFC. `HTTP/2` and `HTTP/3` have no equivalent method allowlist and already forwarded `QUERY`, so the behaviour differed by protocol version. This change adds `QUERY` to that list, so the method is recognized and routed on all three protocol versions. `QUERY` is also added to the `IANA` method registry enforced by the default header validator's `restrict_http_methods` option, so enabling that option no longer rejects a registered method. Recognizing a previously rejected method is user visible, so it is guarded by `envoy.reloadable_features.http1_allow_query_method`, which defaults to true. The guard is latched when the `HTTP/1` parser is constructed, which happens per connection, so flipping it takes effect on new connections without adding a runtime lookup to per-request method validation. Setting it to false restores the previous rejection. Operators could already accept `QUERY` by setting `allow_custom_methods`, but that accepts any token as a method and is marked work-in-progress in the API. ## Additional Description Scoped to Envoy's role as a proxy. Two related areas are deliberately left out: - `QUERY` is not added to `Http::Utility::isSafeRequest()`. Although `RFC 10008` defines `QUERY` as safe and idempotent, that function's callers treat it as \"safe and without content\": it gates whether a request may be sent over `0-RTT` early data, which the default route policy allows for safe requests, and it auto-enables retry on `425`, which for a request with content means buffering that content for the retry. `QUERY` always carries content, so including it changes both behaviours and deserves its own change and guard. A test case pins the current exclusion so the decision is explicit rather than an oversight. - Body-keyed cache keys and the `Accept-Query` response field are origin server concerns rather than proxy ones. The `http_inspector` listener filter is unaffected. Its Balsa path is constructed with `allow_custom_methods` enabled and so never consults the known-method list. Its legacy `http_parser` path rejects every method outside its own list, which is pre-existing behavior already encoded in the `InvalidHttpMethod` test's early return for Balsa. ## Risk Level Low Guarded, and limited to recognizing one additional method token. ## Testing - Unit tests in `balsa_parser_test.cc` covering `QUERY` accepted by default, `QUERY` rejected with the guard disabled, an unrelated method unaffected by the guard, and `QUERY` still accepted via `allow_custom_methods` with the guard off. - Unit test in `codec_impl_test.cc` asserting a `QUERY` request with content-length reaches the decoder with its method, content-type and body intact. - Unit test extension in `base_header_validator_test.cc` for `restrict_http_methods`. - Integration test in `protocol_integration_test.cc` asserting `QUERY` is routed upstream with method and body intact across the full mesh of downstream and upstream protocols, plus a guard-disabled test asserting the `HTTP/1` `400` and that `HTTP/2` and `HTTP/3` are unaffected. ## Docs Changes N/A ## Release Notes ``` changelogs/current/minor_behavior_changes/http__query-method.rst ``` ## Platform Specific Features N/A ## Runtime guard ``` envoy.reloadable_features.http1_allow_query_method ``` defaults to `true`; set to `false` to restore rejecting `QUERY` on `HTTP/1` . Fixes #46404", "url": "https://github.com/envoyproxy/envoy/pull/46496", "createdAt": "2026-08-01T07:07:28Z", "updatedAt": "2026-08-12T18:34:28Z", "timestamp": "2026-08-12T18:34:28Z", "metrics": { "reactions": 0, "comments": 5 }, "labels": [], "author": "guy-with-a-why", "state": "open", "assignees": [ "yanavlasov" ] }, { "id": "github:envoyproxy/envoy:pull_request:46502", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "Support hot restart handoff for connectionless UDP flows", "text": "Commit Message: udp: Support hot restart handoff for connectionless UDP flows Additional Description: The parent instance keeps serving established UDP flows while draining and forwards packets of unknown flows to the child over the hot restart RPC, instead of going dark between drain start and parent shutdown. Risk Level: Medium Testing: Added unit and integration tests, manual Docs Changes: - Added `envoy.resource_limits.listener..udp_flow_limit`. - Added `downstream_flows_active, Gauge`, if equal to the limit, flows might get misrouted during hotrestart Release Notes: Added new_features entry Platform Specific Features: N/A Fixes #34732", "url": "https://github.com/envoyproxy/envoy/pull/46502", "createdAt": "2026-08-01T12:28:12Z", "updatedAt": "2026-08-13T17:36:12Z", "timestamp": "2026-08-13T17:36:12Z", "metrics": { "reactions": 0, "comments": 7 }, "labels": [ "api" ], "author": "filipcacky", "state": "open", "assignees": [ "nezdolik", "markdroth" ] }, { "id": "github:envoyproxy/envoy:pull_request:46526", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "router: support building an SRDS scope key from filter state", "text": "**Commit Message:** support building an SRDS scope key from filter state **Additional Description:** Scope keys could only be built from a request header. This adds a `filter_state` fragment type so a scope key can be built from a filter state object instead. This matters when the value selecting the route table is known at connection time: a network filter can store it in filter state, but a header set by an HTTP filter arrives after the filter chain is created, which is too late for per-route filter config. Connection life span objects are reachable from the stream, so a filter-state fragment resolves the scope on the first route resolution. Risk Level: Low Testing: Unit and Integration tests Docs Changes: Changelog added Release Notes: N.A Platform Specific Features: N.A", "url": "https://github.com/envoyproxy/envoy/pull/46526", "createdAt": "2026-08-04T02:17:18Z", "updatedAt": "2026-08-13T17:31:19Z", "timestamp": "2026-08-13T17:31:19Z", "metrics": { "reactions": 0, "comments": 5 }, "labels": [], "author": "basundhara-c", "state": "open", "assignees": [ "adisuissa", "markdroth", "botengyao" ] }, { "id": "github:envoyproxy/envoy:pull_request:46543", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "mcp_transcoder: Fix Unbounded Recursion DoS", "text": "Commit Message: mcp_transcoder: Fix Unbounded Recursion DoS Additional Description: This PR limits the maximum nesting depth for JSON query parameter processing in constructQueryParams to 100, which mitigates a stack overflow condition caused by maliciously crafted, deeply nested query parameters. Risk Level: Low Testing: Unit tests. Docs Changes: N/A Release Notes: N/A Platform Specific Features: N/A", "url": "https://github.com/envoyproxy/envoy/pull/46543", "createdAt": "2026-08-04T19:18:20Z", "updatedAt": "2026-08-13T17:42:38Z", "timestamp": "2026-08-13T17:42:38Z", "metrics": { "reactions": 0, "comments": 6 }, "labels": [], "author": "guoyilin42", "state": "open", "assignees": [ "tyxia" ] }, { "id": "github:envoyproxy/envoy:pull_request:46545", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "mcp_json_rest_bridge: track request status stats across filter code paths", "text": "Commit Message: mcp_json_rest_bridge: track request status stats across filter code paths Additional Description: This change instruments the `mcp_json_rest_bridge` filter to track request status statistics across all request and response processing code paths. Key details: - Added `incRequestCount()` helper to `McpJsonRestBridgeFilterConfig` using `scope_.counterFromStatNameWithTags()`. - Added request metrics tracking across local replies (`initialize`, `notifications/initialized`, `tools/list`), error responses (`sendErrorResponse`), streaming tool call headers (`encodeHeaders`), and backend responses (`setResponseMetadata`). - Populates `tool_name_` as the `mcp_param` tag **only after** tool validation succeeds to prevent metric cardinality explosion. - Consolidated stat counter assertions into primary request/response unit tests using a new `expectCounter` test helper. Risk Level: Low Testing: * Added unit tests in `config_test.cc` to verify counter is incremented with all/some of the tags. * Added integration tests to simulate multiple requests being aggregated in the counter. * Updated test fixtures in `mcp_json_rest_bridge_filter_test.cc` and `endpoint_keyed_filtering_test.cc` to pass `*stats_store_.rootScope()` to the config constructor. * Added unit test assertions covering all stat counter increments across filter request and response states in `mcp_json_rest_bridge_filter_test.cc`. * All test targets pass. Docs Changes: N/A Release Notes: N/A Platform Specific Features: N/A Runtime Guard: N/A Used AI to generate some of this code and I understand how it works.", "url": "https://github.com/envoyproxy/envoy/pull/46545", "createdAt": "2026-08-04T20:41:02Z", "updatedAt": "2026-08-13T13:16:27Z", "timestamp": "2026-08-13T13:16:27Z", "metrics": { "reactions": 0, "comments": 3 }, "labels": [ "waiting" ], "author": "nahurfonseca", "state": "open", "assignees": [ "mkbehr", "tyxia" ] }, { "id": "github:envoyproxy/envoy:pull_request:46549", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "Using PassthroughState pointer as key for TLS baggage exchange", "text": " This pull request introduces a new mechanism for Istio peer_metadata filters sitting across an internal socket to exchange peer metadata information through thread local storage. The previous implementation would do it in two ways: - Legacy: the filters would exchange information \"in-wire\", through the byte stream. This cause problems as inner sockets for TLS and PROXY would break because of the modified payload. - Using downstream connection ID as a shared unique key between the filters so they can communicate through thread local storage. This also cause problems as the downstream connection ID might be duplicated in the same thread in some scenarios (when using HTTP2 mutiplexing requests). The new implementation will use a shared unique key based on the PassthroughState pointer, which is guaranteed to be unique for every internal socket connection. Commit Message: Additional Description: Risk Level: Testing: Docs Changes: Release Notes: Platform Specific Features: [Optional Runtime guard:] [Optional Fixes #Issue] [Optional Fixes commit #PR or SHA] [Optional Deprecated:] [Optional [API Considerations](https://github.com/envoyproxy/envoy/blob/main/api/review_checklist.md):]", "url": "https://github.com/envoyproxy/envoy/pull/46549", "createdAt": "2026-08-05T10:43:31Z", "updatedAt": "2026-08-13T12:34:32Z", "timestamp": "2026-08-13T12:34:32Z", "metrics": { "reactions": 0, "comments": 2 }, "labels": [ "waiting" ], "author": "grnmeira", "state": "open", "assignees": [ "krinkinmu", "kyessenov" ] }, { "id": "github:envoyproxy/envoy:pull_request:46552", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "network_ext_proc: add onNewConnection event handling", "text": "Commit Message: network_ext_proc: add onNewConnection event handling Additional Description: This PR adds first-class support for `onNewConnection` event handling in the NetworkExternalProcessor Key changes: 1. **API Updates**: - `api/envoy/extensions/filters/network/ext_proc/v3/ext_proc.proto`: Added `ConnectionSendMode process_new_connection` (defaulting to `SKIP` for backwards compatibility). - `api/envoy/service/network_ext_proc/v3/network_external_processor.proto`: Added `message NewConnection` containing downstream remote address, downstream local address, requested server name (SNI), and negotiated protocol (ALPN), and added `NewConnection new_connection = 4` to `ProcessingRequest`. 2. **Filter State Machine**: - In `onNewConnection()`: When enabled (`process_new_connection: SEND`), dispatches `ProcessingRequest` with connection attributes and dynamic metadata, starts a timeout timer, and returns `FilterStatus::StopIteration`. - In `onData()` / `onWrite()`: Halts and buffers incoming payload while `onNewConnection` is pending. - In `onReceiveMessage()`: Parses `dynamic_metadata` into `StreamInfo`, handles `connection_status` (CONTINUE, CLOSE, CLOSE_RST), honors `close_stream_to_ext_proc_server` to allow subsequent raw TCP payload to bypass ext_proc, and resumes the filter chain with `read_callbacks_->continueReading()`. - Timeouts & Error Handling: Respects `failure_mode_allow` to either fail-open (`continueReading()`) or close the connection. 3. **Observability**: - Added `new_connection_sent` counter stat. 4. **Documentation & Release Notes**: - Updated network filter docs and added changelog fragment. AI assistance disclosure: This PR was prepared with AI coding assistance. Risk Level: Low (new configuration field defaults to `SKIP`, preserving existing behavior) Testing: Added comprehensive unit tests in `ext_proc_test.cc` and `config_test.cc` covering request contents, dynamic metadata propagation, stream close bypass, connection close/reset, fail-open/fail-close on timeouts and gRPC errors.", "url": "https://github.com/envoyproxy/envoy/pull/46552", "createdAt": "2026-08-05T14:29:43Z", "updatedAt": "2026-08-12T19:58:58Z", "timestamp": "2026-08-12T19:58:58Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [], "author": "botengyao", "state": "open", "assignees": [] }, { "id": "github:envoyproxy/envoy:pull_request:46558", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "ext_proc: document session affinity configuration", "text": "Commit Message: ext_proc: document session affinity configuration Additional Description: Documents the existing configuration path for keeping requests with the same session key on one external processor endpoint. The downstream key is copied into Envoy gRPC initial metadata and used by a matching cluster-level hash policy. Adds integration coverage for header affinity, passive-cookie affinity, and requests without an affinity key. No production behavior changes are introduced. A runnable Go demonstration is available at https://github.com/dio/ext-proc-session-affinity. AI assistance was used to help prepare the documentation and tests; the submitter reviewed and validated the resulting change. Risk Level: Low Testing: Focused ext_proc integration test. The runnable demo also measured header and passive-cookie affinity across 32 sessions and 160 requests per mode, with both processor endpoints observed and zero affinity violations. Docs Changes: Adds ext_proc session-affinity configuration guidance and examples. Release Notes: N/A Platform Specific Features: N/A Fixes #46159", "url": "https://github.com/envoyproxy/envoy/pull/46558", "createdAt": "2026-08-06T07:34:50Z", "updatedAt": "2026-08-13T00:38:52Z", "timestamp": "2026-08-13T00:38:52Z", "metrics": { "reactions": 0, "comments": 6 }, "labels": [], "author": "dio", "state": "closed", "assignees": [ "phlax", "tyxia", "yanjunxiang-google" ] }, { "id": "github:envoyproxy/envoy:pull_request:46560", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "Avoid excessive hashing for well-known header lookups", "text": " Commit Message: Additional Description: Risk Level: Testing: Docs Changes: Release Notes: Platform Specific Features: [Optional Runtime guard:] [Optional Fixes #Issue] [Optional Fixes commit #PR or SHA] [Optional Deprecated:] [Optional [API Considerations](https://github.com/envoyproxy/envoy/blob/main/api/review_checklist.md):]", "url": "https://github.com/envoyproxy/envoy/pull/46560", "createdAt": "2026-08-06T14:24:17Z", "updatedAt": "2026-08-13T14:51:50Z", "timestamp": "2026-08-13T14:51:50Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [], "author": "etruong42", "state": "open", "assignees": [] }, { "id": "github:envoyproxy/envoy:pull_request:46573", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "Fix listFineGrainLoggers so that it lists loggers", "text": "Also add test to avoid regression Change-Id: I93d401aad43ea51a853725a8939f5b5524b3f8e1 Commit Message: Additional Description: Risk Level: Testing: Docs Changes: Release Notes: Platform Specific Features: [Optional Runtime guard:] [Optional Fixes #Issue] [Optional Fixes commit #PR or SHA] [Optional Deprecated:] [Optional [API Considerations](https://github.com/envoyproxy/envoy/blob/main/api/review_checklist.md):]", "url": "https://github.com/envoyproxy/envoy/pull/46573", "createdAt": "2026-08-07T13:37:05Z", "updatedAt": "2026-08-13T13:28:35Z", "timestamp": "2026-08-13T13:28:35Z", "metrics": { "reactions": 0, "comments": 3 }, "labels": [], "author": "etruong42", "state": "open", "assignees": [ "botengyao" ] }, { "id": "github:envoyproxy/envoy:pull_request:46601", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "Disable fmtlib Unicode support on Windows", "text": "The FMT_UNICODE is a Windows MSVC specific option. It has not effect on Linux build. Risk Level: none Testing: unit tests Docs Changes: no Release Notes: no Platform Specific Features: Windows specific", "url": "https://github.com/envoyproxy/envoy/pull/46601", "createdAt": "2026-08-09T17:39:36Z", "updatedAt": "2026-08-13T15:49:00Z", "timestamp": "2026-08-13T15:49:00Z", "metrics": { "reactions": 0, "comments": 5 }, "labels": [ "no stalebot" ], "author": "yanavlasov", "state": "open", "assignees": [] }, { "id": "github:envoyproxy/envoy:pull_request:46603", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "ai_protocol_manager: add response handling and extract response token usage oai, ahth, gemini", "text": "Adds response-side (encode-path) handling to the AI Protocol Manager filter: 2xx SSE and JSON responses in the OpenAI (Chat Completions + Responses API), Anthropic (Messages), and Gemini (`generateContent`/`streamGenerateContent`) dialects are observed as they stream through, and normalized token usage is published as dynamic metadata at a clean end of stream. Observe-only: the filter never stops iteration or mutates the response, and extraction failures cannot affect the stream. - one namespace (default `envoy.ai.token_usage`) in both metadata forms — a typed `envoy.data.ai.v3.TokenUsage` record (authoritative, full `uint64` precision) and an untyped Struct projection of it for `%DYNAMIC_METADATA%`/CEL. ext_proc consumers receive it via `metadata_options.forwarding_namespaces`. - `input_tokens`/`output_tokens` are inclusive in every dialect (cache, tool-use, and reasoning buckets are subset breakdowns), and `total_tokens` is their sum; a disagreeing provider total is kept as `reported_total_tokens`. Counts accumulate natively per event and are canonicalized once at end of stream. `extraction_status` (`complete`/`partial`) reports extraction quality. - dialect auto-detected from response shape, or pinned via `api_format` (a wire format, not a provider identity). The extractor config is a `oneof` for future custom extractors. - SSE state hard-capped by `max_event_size` (1MiB default), JSON by `max_inspected_body_size`, per-stream parse work by `max_parsed_events`; in-frame events are zero-copy, non-usage events are skipped before parsing, and buffers charge the stream's memory account. - dual filter with identical extraction in either chain; first publication owns the namespace. `request_handling.payload_offload_enabled: false` enables a response-only installation (pure request passthrough), e.g. for observation on a DFP egress cluster. For API shepherds: (1) placement of the emitted message under `envoy.data.ai.v3` (WIP-annotated); (2) the future `custom_extractor` oneof member. Deferred with rationale: selective streaming (SAX) extractor, common SSE decoder shared with `sse_to_metadata`, per-route `api_format` pinning, usage-on-abort publication. **Testing:** - E2E (live providers, DFP + auto-detect) — access-log records from a real run: | Provider | Framing | Extracted (in/out/total) | Notes | |---|---|---|---| | OpenAI `gpt-4o-mini` | JSON + SSE | 13 / 7 / 20 | terminal `include_usage` chunk | | Anthropic `claude-haiku-4-5` | JSON + SSE | 13 / 10 / 23 | total computed (absent on wire) | | Gemini `gemini-3.6-flash` | JSON | 6 / 661 / 667 | 654 reasoning tokens summed into output | | Gemini `gemini-3.6-flash` | SSE | 6 / 760 / 766 | cumulative snapshots, last wins | All six requests: `extraction_status: complete`, auto-detected `api_format`, zero parse-error/partial/budget counters. Also validated live: OpenAI Responses API, OpenAI prompt caching (`cached_input_tokens: 2816`), and Anthropic cache write/read (wire `input_tokens: 9` + `cache_read: 6761` → canonical `input_tokens: 6770`). https://github.com/botengyao/envoy/pull/1736/changes Commit Message: add response handling and extract response token usage oai, ahth, gemini Additional Description: Risk Level: Low — opt-in behavior in an alpha (work-in-progress) filter; observe-only and fail-open by construction. Testing: all unit, integration, fuzz, and benchmark tests are added. Docs Changes: yes", "url": "https://github.com/envoyproxy/envoy/pull/46603", "createdAt": "2026-08-09T21:54:17Z", "updatedAt": "2026-08-12T17:42:07Z", "timestamp": "2026-08-12T17:42:07Z", "metrics": { "reactions": 0, "comments": 2 }, "labels": [ "api" ], "author": "botengyao", "state": "open", "assignees": [ "penguingao", "wbpcode" ] }, { "id": "github:envoyproxy/envoy:pull_request:46607", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "formatter: add formatValueTo to reduce allocation of protobuf value", "text": "Commit Message: formatter: add formatValueTo to reduce allocation of protobuf value Additional Description: Similar to https://github.com/envoyproxy/envoy/pull/46593, but support the typed value. ``` Baseline — HEAD BM_AccessLogFormatter_mean 131 ns 131 ns 5 BM_AccessLogFormatterTextMockJson_mean 131 ns 131 ns 5 BM_JsonAccessLogFormatter_mean 242 ns 242 ns 5 BM_JsonAccessLogFormatterKeepEmptyValues_mean 197 ns 196 ns 5 BM_JsonAccessLogFormatterOmitEmptyValues_mean 334 ns 333 ns 5 Your branch BM_AccessLogFormatter_mean 120 ns 120 ns 5 BM_AccessLogFormatterTextMockJson_mean 121 ns 121 ns 5 BM_JsonAccessLogFormatter_mean 172 ns 172 ns 5 BM_JsonAccessLogFormatterKeepEmptyValues_mean 130 ns 130 ns 5 BM_JsonAccessLogFormatterOmitEmptyValues_mean 287 ns 287 ns 5 ``` | Benchmark | before | after | delta | |---|---|---|---| | `BM_AccessLogFormatter` | 131 | 120 | −8.4% | | `BM_AccessLogFormatterTextMockJson` | 131 | 121 | −7.6% | | `BM_JsonAccessLogFormatter` | 242 | 172 | −28.9% | | `BM_JsonAccessLogFormatterKeepEmptyValues` | 196 | 130 | −33.7% | | `BM_JsonAccessLogFormatterOmitEmptyValues` | 333 | 287 | −13.8% | Risk Level: low. Testing: unit. Docs Changes: n/a. Release Notes: n/a. Platform Specific Features: n/a.", "url": "https://github.com/envoyproxy/envoy/pull/46607", "timestamp": "2026-08-12T12:39:47Z", "metrics": { "reactions": 0, "comments": 4 }, "labels": [], "author": "wbpcode", "assignees": [], "change": "new" }, { "id": "github:envoyproxy/envoy:pull_request:46613", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "network: send zero-length UDP datagrams", "text": "Preserve empty datagrams across all UDP send paths. Justification: RFC 768 permits UDP datagrams with an empty payload: the minimum UDP Length is 8 octets, corresponding to the UDP header alone. Envoy currently treats these valid datagrams as no-op writes and silently drops them. This change ensures they reach the socket send operation for connected and unconnected UDP sockets. Commit Message: Additional Description: Risk Level: Testing: Done Docs Changes: Release Notes: Platform Specific Features:", "url": "https://github.com/envoyproxy/envoy/pull/46613", "createdAt": "2026-08-10T13:37:06Z", "updatedAt": "2026-08-13T14:42:44Z", "timestamp": "2026-08-13T14:42:44Z", "metrics": { "reactions": 0, "comments": 2 }, "labels": [], "author": "nezdolik", "state": "open", "assignees": [ "kyessenov", "agrawroh" ] }, { "id": "github:envoyproxy/envoy:pull_request:46614", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "reverse_tunnel: add tunnel setup latency stats", "text": "## Commit Message reverse_tunnel: add tunnel setup latency stats ## Description Adds max_tunnel_setup_time on the downstream reverse-tunnel initiator and emits tunnel_setup_time (histogram) / tunnel_setup_time_exceeded (counter) for how long it takes a host to reach its configured connection count. Attempts continue after the deadline; late completions are not recorded as setup-time samples. Episode timing is reused across retries within an establishment episode and resets when capacity drops. ## Testing Unit tests + integ tests for the counter and histogram added.", "url": "https://github.com/envoyproxy/envoy/pull/46614", "timestamp": "2026-08-12T12:28:37Z", "metrics": { "reactions": 0, "comments": 2 }, "labels": [ "api" ], "author": "aakugan", "assignees": [], "change": "new" }, { "id": "github:envoyproxy/envoy:pull_request:46621", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "quic: promote HTTP/3 API status from alpha to stable", "text": "QUIC/HTTP3 is well-supported both internally and externally in Envoy. CVEs in it are treated with the highest priority. It's long-overdue to take it out of alpha. Changes: - Remove 'QUIC upstream support is currently not ready for internet use' warnings from http_protocol_options.proto (ExplicitHttpConfig, UseDownstreamHttpConfig, AutoHttpConfig). - Remove stale '(soon)' qualifier from AutoHttpConfig comment. - Remove 'QUIC implementation is not production ready yet' comment from the HTTP3 CodecClientType enum in http.proto. - Remove the alpha/not-production-ready warning from the HTTP/3 arch overview documentation. - Promote all QUIC extensions from alpha to stable in extensions_metadata.yaml: - envoy.quic.proof_source.filter_chain - envoy.quic.server_preferred_address.fixed - envoy.quic.server_preferred_address.datasource - envoy.quic.deterministic_connection_id_generator - envoy.quic.connection_id_generator.quic_lb - envoy.quic.crypto_stream.server.quiche - envoy.quic.connection_debug_visitor.basic - envoy.quic.connection_debug_visitor.quic_stats Risk Level: Low (documentation and metadata only) Testing: N/A (no code changes) Created with AI", "url": "https://github.com/envoyproxy/envoy/pull/46621", "createdAt": "2026-08-10T22:48:31Z", "updatedAt": "2026-08-13T15:59:15Z", "timestamp": "2026-08-13T15:59:15Z", "metrics": { "reactions": 0, "comments": 3 }, "labels": [], "author": "abeyad", "state": "closed", "assignees": [ "adisuissa", "RyanTheOptimist" ] }, { "id": "github:envoyproxy/envoy:pull_request:46622", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "c-ares: disable shared resolver by default", "text": "Commit Message: c-ares: disable shared resolver by default Additional Description: DnsFilter would call createDnsResolver() from a workerthread that would cause a race when sharing dns resolvers. Turn off this feature until the race is fixed. Relates to https://github.com/envoyproxy/envoy/pull/46577 and https://github.com/envoyproxy/envoy/pull/45073 Risk Level: low Testing: Docs Changes: Release Notes: Platform Specific Features:", "url": "https://github.com/envoyproxy/envoy/pull/46622", "createdAt": "2026-08-10T23:28:22Z", "updatedAt": "2026-08-13T15:35:31Z", "timestamp": "2026-08-13T15:35:31Z", "metrics": { "reactions": 0, "comments": 6 }, "labels": [], "author": "andy-fong", "state": "closed", "assignees": [] }, { "id": "github:envoyproxy/envoy:pull_request:46640", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "cluster specifier: support new attempt aware cluster specifier", "text": "Commit Message: cluster specifier: support new attempt aware cluster specifier Additional Description: Risk Level: Testing: Docs Changes: Release Notes: Platform Specific Features: [Optional Runtime guard:] [Optional Fixes #Issue] [Optional Fixes commit #PR or SHA] [Optional Deprecated:] [Optional [API Considerations](https://github.com/envoyproxy/envoy/blob/main/api/review_checklist.md):]", "url": "https://github.com/envoyproxy/envoy/pull/46640", "timestamp": "2026-08-12T13:20:24Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [ "api" ], "author": "wbpcode", "assignees": [], "change": "new" }, { "id": "github:envoyproxy/envoy:pull_request:46645", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "APM: add utilities to define and validate JSON schema. add the first schema - OpenAI chat completion schema", "text": "Commit Message: add utilities to define and validate JSON schema. add the first schema - OpenAI chat completion schema This allows us to structurally define a JSON payload schema for AI requests. It is useful for validation, and later transcoding. This is part of #44681. I used AI to generate this PR. I have read and fully understand this PR. Additional Description: https://github.com/penguingao/thoughts/blob/main/20260727_AI_FILTER.md Risk Level: Medium Testing: unit tests Docs Changes: updated the extension docs, but this is still an alpha filter under development Release Notes: N/A - WIP alpha filter Platform Specific Features: no", "url": "https://github.com/envoyproxy/envoy/pull/46645", "createdAt": "2026-08-11T16:25:52Z", "updatedAt": "2026-08-12T14:22:25Z", "timestamp": "2026-08-12T14:22:25Z", "metrics": { "reactions": 0, "comments": 4 }, "labels": [], "author": "penguingao", "state": "open", "assignees": [ "wbpcode", "botengyao", "tyxia" ], "change": "updated" }, { "id": "github:envoyproxy/envoy:pull_request:46650", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "repo: remove zuercher from code ownership/maintainer", "text": "Risk Level: low Testing: n/a Docs Changes: n/a Release Notes: n/a Platform Specific Features: n/a", "url": "https://github.com/envoyproxy/envoy/pull/46650", "createdAt": "2026-08-11T19:02:06Z", "updatedAt": "2026-08-12T14:10:14Z", "timestamp": "2026-08-12T14:10:14Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "zuercher", "state": "closed", "assignees": [], "change": "updated" }, { "id": "github:envoyproxy/envoy:pull_request:46655", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "filesystem: refactor win32 watcher_impl to use absl mutex and fix buffer alignment", "text": "Additional Description: Refactors the Win32 filesystem watcher (`WatcherImpl`): - Replaces `` (`concurrency::concurrent_queue`) with a thread-safe `ThreadSafeQueue` using `absl::Mutex`. This eliminates duplicate symbol link conflicts between `libc++` and MSVC `libconcrt.lib`. - Changes `DirectoryWatch` buffer type from `std::vector` to `std::vector` ensuring 4-byte DWORD alignment required by `ReadDirectoryChangesW` and `FILE_NOTIFY_INFORMATION`. - Synchronizes access to `DirectoryWatch::watches_` with an `absl::Mutex`. - Adds `callAndLogOnError` with exception handling and rate-limited logging. - Updates `watcher_impl_test.cc` to ensure file handles are cleanly closed before read events and flushes. Risk Level: medium (Win32 filesystem watcher refactor) Testing: `bazel test //test/common/filesystem:watcher_impl_test` Docs Changes: n/a Release Notes: Included under bug_fixes for Win32 watcher Platform Specific Features: Windows", "url": "https://github.com/envoyproxy/envoy/pull/46655", "createdAt": "2026-08-11T19:40:08Z", "updatedAt": "2026-08-13T13:11:30Z", "timestamp": "2026-08-13T13:11:30Z", "metrics": { "reactions": 0, "comments": 2 }, "labels": [ "waiting" ], "author": "citrus7", "state": "open", "assignees": [ "yanavlasov", "tyxia" ] }, { "id": "github:envoyproxy/envoy:pull_request:46656", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "Avoid unnecesary renaming of watcher_target.yaml", "text": "This avoids the race condition where watcher_target.yaml is not present Change-Id: I7f8c67023ac31f3a9cac294caca5c0d18c30ee1d Commit Message: Additional Description: Risk Level: Testing: Docs Changes: Release Notes: Platform Specific Features: [Optional Runtime guard:] [Optional Fixes #Issue] [Optional Fixes commit #PR or SHA] [Optional Deprecated:] [Optional [API Considerations](https://github.com/envoyproxy/envoy/blob/main/api/review_checklist.md):]", "url": "https://github.com/envoyproxy/envoy/pull/46656", "createdAt": "2026-08-11T19:50:47Z", "updatedAt": "2026-08-13T01:59:51Z", "timestamp": "2026-08-13T01:59:51Z", "metrics": { "reactions": 0, "comments": 3 }, "labels": [], "author": "etruong42", "state": "open", "assignees": [ "phlax" ] }, { "id": "github:envoyproxy/envoy:pull_request:46657", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "c-ares: move dns shared resolver logic to upstream cluster", "text": "Commit Message: c-ares: move dns shared resolver logic to upstream cluster Additional Description: In #45073 I added qcache_max_ttl for the c-ares resolver and shared the resolver across clusters with identical c-ares configs so the query cache is shared. However, I didn't realize the UDP DNS filter also calls CaresDnsResolverFactory::createDnsResolver() directly, once per worker thread with that worker's dispatcher. Two workers with the same config would share a resolver bound to the wrong dispatcher, causing c-ares callbacks to fire on the wrong event loop. Instead of adding a mutex and keying on dispatcher identity, I moved the sharing logic into the upstream cluster layer. The new `ClusterDnsResolverCache` is owned by ProdClusterManagerFactory (one per server, main thread only), so createDnsResolver() callers like the DNS filter are unaffected and always get their own resolver. Other notes: - Sharing remains limited to c-ares; other resolver types get one resolver per cluster as before. The lookup key is hashed at the `TypedExtensionConfig` level rather than on the unpacked c-ares config. - The default server-wide resolver (dnsResolver()) is already shared for clusters without a custom resolver config; I deliberately left that path unchanged to minimize scope. - Because of some workaround people used I found after my original PR merged(see [Comment](https://github.com/envoyproxy/envoy/pull/45073#issuecomment-4974660723)), I decided to leave the `envoy.restart_features.shared_cares_dns_resolver` to false by default for now. Also related to https://github.com/envoyproxy/envoy/pull/46577 AI Disclosure: this PR is mostly generated by AI with just a few hand edit and updates. I did iterated several times with AI to come up with this solution and understand all the changes. Risk Level: low Testing: Added unit tests and also manually tested with tcpdump and the shared resolver feature on and off to confirm the query cache is working to reduce dns lookup to the server. Docs Changes: Release Notes: Fixed race caused by shared c-ares dns resolvers. Platform Specific Features: [Optional Runtime guard:] \"envoy.restart_features.shared_cares_dns_resolver\" is set to false by default now", "url": "https://github.com/envoyproxy/envoy/pull/46657", "timestamp": "2026-08-12T13:47:39Z", "metrics": { "reactions": 0, "comments": 2 }, "labels": [], "author": "andy-fong", "assignees": [], "change": "new" }, { "id": "github:envoyproxy/envoy:pull_request:46658", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "tls_inspector: fix GREASE filtering in JA4_c signature algorithms", "text": "## Summary The JA4 fingerprint's third component hashes the ClientHello's extension list joined to its `signature_algorithms` list. Per the [JA4 spec](https://github.com/FoxIO-LLC/ja4/blob/main/technical_details/JA4.md), GREASE codepoints must be excluded everywhere they appear — including in `signature_algorithms`. `getJA4ExtensionHash` already applies `isNotGrease` to extension type IDs, and `getJA4CipherHash`, `countCiphers`, and `countExtensions` apply it to their respective inputs. The `signature_algorithms` collection loop was the sole exception, pushing every 16-bit codepoint from the extension body unconditionally. Clients that inject a GREASE value into `signature_algorithms` (e.g. Chrome's per-handshake random GREASE selection, drawn from the 16 reserved code points `0x0a0a`, `0x1a1a`, …, `0xfafa`) therefore produce a **different** JA4_c hash per connection while all other parts of the fingerprint are identical — resulting in many-to-one hash collapse when compared against spec-compliant implementations. ## Fix Guard the `sig_algs.push_back(sig_alg)` call in `getJA4ExtensionHash` with `isNotGrease(sig_alg)`, matching the treatment already applied everywhere else in the file. ## Test plan - [x] Added `TEST(JA4Fingerprinter, GreaseValueFilteredFromSignatureAlgorithms)` in `ja4_fingerprint_test.cc` that constructs two \\`SSL_CLIENT_HELLO\\`s identical except for a GREASE codepoint (\\`0x0a0a\\`) in \\`signature_algorithms\\` and asserts \\`JA4Fingerprinter::create\\` produces the same fingerprint for both. - [x] \\`bazel test //test/extensions/filters/listener/tls_inspector:ja4_fingerprint_test\\` passes locally. ## Notes - No existing entry in the \\`JA4_TEST_VECTORS\\` table in \\`tls_inspector_ja4_test.cc\\` contains a GREASE codepoint inside its \\`signature_algorithms\\` extension body — all GREASE bytes in those captures live in extensions/versions/keyshare slots, which are already filtered correctly — so its pinned expected hashes remain valid. - This change was drafted with AI assistance and reviewed by the author.", "url": "https://github.com/envoyproxy/envoy/pull/46658", "createdAt": "2026-08-11T22:04:01Z", "updatedAt": "2026-08-13T17:45:55Z", "timestamp": "2026-08-13T17:45:55Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [], "author": "dangle1", "state": "open", "assignees": [] }, { "id": "github:envoyproxy/envoy:pull_request:46660", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "tidy: enforce and apply C++20 container `contains()`", "text": "Enable the `readability-container-contains` clang-tidy check so that `count(k)`/`find(k) != end()` membership tests are flagged going forward, and apply the `.contains()` conversion across the non-extensions code (the extensions tree was cleaned up separately). Readability cleanup with no behavior change.", "url": "https://github.com/envoyproxy/envoy/pull/46660", "createdAt": "2026-08-12T02:12:42Z", "updatedAt": "2026-08-13T12:44:57Z", "timestamp": "2026-08-13T12:44:57Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "jwendell", "state": "closed", "assignees": [] }, { "id": "github:envoyproxy/envoy:pull_request:46663", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "cleanup: replace erase-remove idiom with std::erase_if or absl::erase_if", "text": "### Description Replace the traditional erase-remove idiom with the more concise `std::erase_if` and `absl::erase_if` APIs where applicable. This improves readability by expressing the intent to remove elements matching a predicate directly, while preserving the existing behavior. ### Changes Replace `std::remove_if` followed by `erase` with `std::erase_if` for standard containers. Replace the same pattern with `absl::erase_if` for supported Abseil containers. No functional behavior changes are intended.", "url": "https://github.com/envoyproxy/envoy/pull/46663", "createdAt": "2026-08-12T09:23:38Z", "updatedAt": "2026-08-13T12:27:44Z", "timestamp": "2026-08-13T12:27:44Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [], "author": "Amila-Rukshan", "state": "open", "assignees": [ "botengyao" ] }, { "id": "github:envoyproxy/envoy:pull_request:46664", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "rds: make the init manager for rds works for filter_chain and oauth2", "text": "Commit Message: rds: make the init manager for rds works for filter_chain and oauth2 Additional Description: Now, all configuration on the route could optionally add an async warming target to the route level init manager. The change of oauth2 showed how it works. Risk Level: n/a. Testing: unit. Docs Changes: n/a. Release Notes: added. Platform Specific Features: n/a.", "url": "https://github.com/envoyproxy/envoy/pull/46664", "createdAt": "2026-08-12T09:51:11Z", "updatedAt": "2026-08-13T03:25:33Z", "timestamp": "2026-08-13T03:25:33Z", "metrics": { "reactions": 0, "comments": 5 }, "labels": [], "author": "wbpcode", "state": "open", "assignees": [ "htuch" ] }, { "id": "github:envoyproxy/envoy:pull_request:46667", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "fix: health check probes blocked indefinitely when EDS initialFetchTimeout is 0s", "text": "_Commit Message:_ when a cluster is configured with EDS and initialFetchTimeout: 0s, the cluster stays in warming state indefinitely until EDS delivers its first response, no timeout fires to unblock it. _Additional Description:_ added a bypass in ClusterImplBase::setHealthChecker(). when health_check_after_cluster_warming is enabled, health checks are still started immediately if both conditions hold: 1. the EDS config source has initialFetchTimeout: 0s (hasZeroInitialFetchTimeout() == true) 2. there are no pending SDS init targets (init_manager_.uninitializedCount() == 0) _Risk Level:_ Low _Testing:_ Will be added soon. _Release Notes:_ fix health check probes being blocked indefinitely on EDS clusters configured with initialFetchTimeout: 0s. With health_check_after_cluster_warming enabled(default), health checks are no longer deferred when EDS warming has no timeout deadline. Fixes #46666", "url": "https://github.com/envoyproxy/envoy/pull/46667", "createdAt": "2026-08-12T15:33:25Z", "updatedAt": "2026-08-13T08:06:21Z", "timestamp": "2026-08-13T08:06:21Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [], "author": "yuehaii", "state": "open", "assignees": [] }, { "id": "github:envoyproxy/envoy:pull_request:46668", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "Rescope Logger::Levels enum so it can be moved to envoy/ directory", "text": "The main change is in the source/common/common/base_logger.h, moving the Levels enum out of the Logger class into the outer Logger namespace. This is intermediate step to using this enum in Envoy's interfaces in the envoy/ directory. This will prevent leaking of the spdlog dependency to proprietary components that need to manipulate Envoy's log level programmatically. Risk Level: low Testing: unit tests Docs Changes: no Release Notes: no Platform Specific Features: no", "url": "https://github.com/envoyproxy/envoy/pull/46668", "createdAt": "2026-08-12T15:37:40Z", "updatedAt": "2026-08-13T15:35:25Z", "timestamp": "2026-08-13T15:35:25Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [], "author": "yanavlasov", "state": "closed", "assignees": [] }, { "id": "github:envoyproxy/envoy:pull_request:46669", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "orca: make OOB active_sessions gauge composable across managers", "text": " Commit Message: Additional Description: Risk Level: Testing: Docs Changes: Release Notes: Platform Specific Features: [Optional Runtime guard:] [Optional Fixes #Issue] [Optional Fixes commit #PR or SHA] [Optional Deprecated:] [Optional [API Considerations](https://github.com/envoyproxy/envoy/blob/main/api/review_checklist.md):]", "url": "https://github.com/envoyproxy/envoy/pull/46669", "createdAt": "2026-08-12T16:23:40Z", "updatedAt": "2026-08-12T16:37:14Z", "timestamp": "2026-08-12T16:37:14Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [], "author": "jukie", "state": "closed", "assignees": [] }, { "id": "github:envoyproxy/envoy:pull_request:46670", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "load_aware_locality: add out-of-band ORCA reporting", "text": "Commit Message: implement out-of-band ORCA reporting for load_aware_locality Additional Description: Follow-up to https://github.com/envoyproxy/envoy/pull/45725 to wire up ORCA out-of-band reporting with the additional below changes: - Adds oob_reporting_config proto field - Graduates envoy.load_balancing_policies.load_aware_locality from `wip` to `alpha` in extensions_metadata.yaml. - Fixes `lb_orca_oob.active_sessions` accounting in the shared OrcaOobManager Risk Level: Low - still an alpha marked policy and opt-in only Testing: Added end-to-end OOB integration test and other coverage Docs Changes: Yes Release Notes: Updated existing (still unreleased) Platform Specific Features: N/A xRef https://github.com/envoyproxy/envoy/issues/43665 xRef https://github.com/envoyproxy/envoy/issues/6614", "url": "https://github.com/envoyproxy/envoy/pull/46670", "createdAt": "2026-08-12T17:29:45Z", "updatedAt": "2026-08-13T04:22:17Z", "timestamp": "2026-08-13T04:22:17Z", "metrics": { "reactions": 0, "comments": 5 }, "labels": [ "api" ], "author": "jukie", "state": "open", "assignees": [ "markdroth" ] }, { "id": "github:envoyproxy/envoy:pull_request:46671", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "ExtProc: clarify docs on end_of_stream_without_message field", "text": "Commit Message: ExtProc: clarify docs on end_of_stream_without_message field Additional Description: Clarify description of the field, and mark it as not-implemented-hide to exclude from Envoy docs. Risk Level: Low Testing: N/A Docs Changes: Included in PR Release Notes: N/A Platform Specific Features: N/A CC @yanjunxiang-google", "url": "https://github.com/envoyproxy/envoy/pull/46671", "createdAt": "2026-08-12T18:15:08Z", "updatedAt": "2026-08-12T18:15:20Z", "timestamp": "2026-08-12T18:15:20Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [ "api" ], "author": "markdroth", "state": "open", "assignees": [ "wbpcode" ] }, { "id": "github:envoyproxy/envoy:pull_request:46672", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "[draft] dym: go sdk for udp listener filter", "text": " Commit Message: Additional Description: Risk Level: Testing: Docs Changes: Release Notes: Platform Specific Features: [Optional Runtime guard:] [Optional Fixes #Issue] [Optional Fixes commit #PR or SHA] [Optional Deprecated:] [Optional [API Considerations](https://github.com/envoyproxy/envoy/blob/main/api/review_checklist.md):]", "url": "https://github.com/envoyproxy/envoy/pull/46672", "createdAt": "2026-08-12T21:04:40Z", "updatedAt": "2026-08-13T14:11:02Z", "timestamp": "2026-08-13T14:11:02Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [], "author": "ovadiagal", "state": "open", "assignees": [] }, { "id": "github:envoyproxy/envoy:pull_request:46673", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "Order dependent bug", "text": "Commit Message: Fix flaky order-dependent stats_test failures via physical test file separation Additional Description: The tests `NonNumberValueFormatted` and `GaugeNonNumberValueFormatted` both trigger identical error logs emitted via `ENVOY_LOG_PERIODIC_MISC` in `stats.cc`. Because this macro rate-limits logging to prevent log spam, running these tests consecutively in the same target process led to one suppressing the other, causing flaky test failures under randomized execution ordering. Risk Level: low Testing: NA Docs Changes: NA Release Notes: NA Platform Specific Features: NA", "url": "https://github.com/envoyproxy/envoy/pull/46673", "createdAt": "2026-08-12T21:06:33Z", "updatedAt": "2026-08-13T17:40:18Z", "timestamp": "2026-08-13T17:40:18Z", "metrics": { "reactions": 0, "comments": 4 }, "labels": [], "author": "Wenwei-Zhao", "state": "open", "assignees": [ "adisuissa", "antoniovleonti" ] }, { "id": "github:envoyproxy/envoy:pull_request:46674", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "fix: wasm remote code fetch race writing negative cache entry", "text": "● Problem When multiple Envoy worker threads simultaneously call createWasm() for a remote wasm plugin, Thread A starts the HTTP fetch and marks the cache entry in_progress = true. Threads B–N find the entry in_progress, call cb(nullptr) to signal failure, then fall through (missing return) to the code.empty() block. There, they write a negative cache entry (TTL=10s) and start competing fetch attempts. Thread A's successful download is now racing against a poisoned negative cache. For the next 10 seconds, any new call to createWasm() hits RemoteLoadCacheNegativeHit and immediately fails, holding all wasm-filtered requests for up to 10 seconds before fail_open releases them. ``` if (it->second.in_progress) { cb(nullptr); // ← signals FAILURE to the plugin } // ← NO return! falls through code = it->second.code; // empty (Thread 1 still downloading) if (code.empty()) { fetch = true; // ← Thread 2 ALSO starts downloading now it->second.in_progress = true; } ``` ● Fix Add return false immediately after cb(nullptr) in the in_progress branch. Threads B–N still signal failure to the plugin (allowing fail_open to pass the request through), but they no longer fall through to write the negative cache entry or start duplicate fetches. Thread A's download completes uncontested, populates the cache as a successful hit, and all subsequent requests resolve instantly. ● Impact - Eliminates the RemoteLoadCacheNegativeHit cascade that causes 10-second dead zones for wasm-filtered requests - Fixes the CPU spike from competing parallel fetches (all threads racing to download the same binary) - Related: https://github.com/envoyproxy/envoy/issues/25052", "url": "https://github.com/envoyproxy/envoy/pull/46674", "createdAt": "2026-08-12T22:28:46Z", "updatedAt": "2026-08-12T22:29:24Z", "timestamp": "2026-08-12T22:29:24Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [], "author": "eformat", "state": "open", "assignees": [] }, { "id": "github:envoyproxy/envoy:pull_request:46675", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "transport_socket(http_11_proxy): add Proxy-Authorization header support", "text": "Commit Message: This patch adds support in HTTP/1.1 Proxy for HTTP proxy authorization. The HTTP/1.1 Proxy looks up the encoded credentials in its host's typed filter metadata and sends it with the Proxy-Authorization HTTP header in the CONNECT request to the proxy. Proxy authorization is still unsupported when filter state metadata is used. Additional Description: AI used to write tests Risk Level: Low Testing: Unit and integration test added Docs Changes: No Release Notes: Platform Specific Features: No", "url": "https://github.com/envoyproxy/envoy/pull/46675", "createdAt": "2026-08-12T23:30:17Z", "updatedAt": "2026-08-12T23:53:10Z", "timestamp": "2026-08-12T23:53:10Z", "metrics": { "reactions": 0, "comments": 2 }, "labels": [], "author": "glennc24", "state": "open", "assignees": [] }, { "id": "github:envoyproxy/envoy:pull_request:46676", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "Allow connection teardown even when cert selection is not yet complete", "text": "https://github.com/envoyproxy/envoy/pull/45755 allowed the socket state to transition to `ShutdownSent` before cert selection is complete (as intended). However, this could cause `ENVOY_BUG` to be thrown when `SslSocket::onAsynchronousCertificateSelectionComplete()` is invoked. This patch updates `SslSocket::onAsynchronousCertificateSelectionComplete` to allow this socket state which is consistent with the implementation of `SslSocket::onAsynchronousCertValidationComplete` and avoids the `ENVOY_BUG` in the case of valid states such as `ShutdownSent`. Change-Id: I155b874accd54affa65bfa0b744ff99154060570 Commit Message: Additional Description: Risk Level: Testing: Docs Changes: Release Notes: Platform Specific Features: [Optional Runtime guard:] [Optional Fixes #Issue] [Optional Fixes commit #PR or SHA] [Optional Deprecated:] [Optional [API Considerations](https://github.com/envoyproxy/envoy/blob/main/api/review_checklist.md):]", "url": "https://github.com/envoyproxy/envoy/pull/46676", "createdAt": "2026-08-13T01:58:15Z", "updatedAt": "2026-08-13T15:40:27Z", "timestamp": "2026-08-13T15:40:27Z", "metrics": { "reactions": 0, "comments": 2 }, "labels": [], "author": "etruong42", "state": "open", "assignees": [] }, { "id": "github:envoyproxy/envoy:pull_request:46679", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "Add extension point to OpenTelemetry tracer for custom exporters.", "text": " ### Commit Message Added support for custom exporters in the OpenTelemetry tracer. In implementing this feature, I also changed some existing code in opentelemetry_tracer_impl.cc to make it more thread safe, such as moving the instantiation of the gRPC client factory out of the worker threads and into the main thread. This means that if the factory creation returns an error, it won't crash the worker thread, and thereby the whole Envoy proxy. ### Additional Description AI was used to generate the code and tests in this PR. I have reviewed – and fully understand – the code. ### Risk Level Low ### Testing I've added unit tests testing both the control plane and data plane code flows. ### Docs Changes None required ### Release Notes Added a changelog under new_features (area: tracing) ### Platform Specific Features None", "url": "https://github.com/envoyproxy/envoy/pull/46679", "createdAt": "2026-08-13T07:48:06Z", "updatedAt": "2026-08-13T16:44:58Z", "timestamp": "2026-08-13T16:44:58Z", "metrics": { "reactions": 0, "comments": 2 }, "labels": [ "api" ], "author": "jakebennert", "state": "open", "assignees": [ "mattklein123" ] }, { "id": "github:envoyproxy/envoy:pull_request:46682", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "Restrict local reply streaming integration tests", "text": "... so that it runs only on Envoy gRPC Change-Id: If3ff45c3ee9db39b14ed506a7ef85ae00ec7db24 Commit Message: Additional Description: Risk Level: Testing: Docs Changes: Release Notes: Platform Specific Features: [Optional Runtime guard:] [Optional Fixes #Issue] [Optional Fixes commit #PR or SHA] [Optional Deprecated:] [Optional [API Considerations](https://github.com/envoyproxy/envoy/blob/main/api/review_checklist.md):]", "url": "https://github.com/envoyproxy/envoy/pull/46682", "createdAt": "2026-08-13T12:13:50Z", "updatedAt": "2026-08-13T15:02:57Z", "timestamp": "2026-08-13T15:02:57Z", "metrics": { "reactions": 0, "comments": 2 }, "labels": [], "author": "etruong42", "state": "open", "assignees": [] }, { "id": "github:envoyproxy/envoy:pull_request:46683", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "Ensure upstream hosts have rebalanced utilization", "text": "... before asserting new traffic patterns in test Commit Message: Additional Description: Risk Level: Testing: Docs Changes: Release Notes: Platform Specific Features: [Optional Runtime guard:] [Optional Fixes #Issue] [Optional Fixes commit #PR or SHA] [Optional Deprecated:] [Optional [API Considerations](https://github.com/envoyproxy/envoy/blob/main/api/review_checklist.md):]", "url": "https://github.com/envoyproxy/envoy/pull/46683", "createdAt": "2026-08-13T13:14:57Z", "updatedAt": "2026-08-13T15:38:58Z", "timestamp": "2026-08-13T15:38:58Z", "metrics": { "reactions": 0, "comments": 2 }, "labels": [], "author": "etruong42", "state": "open", "assignees": [] }, { "id": "github:envoyproxy/envoy:pull_request:46684", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "coroutine: add ASSIGN_OR_CO_RETURN and CO_RETURN_IF_ERROR macros", "text": "Commit Message: These are the macros that mirror directly `RETURN_IF_ERROR` and `ASSIGN_OR_RETURN` but for `Envoy::Coroutine::Task` and `Envoy::Coroutine::Task>` coroutines. Additional Description: Risk Level: low Testing: unit test Docs Changes: N/A Release Notes: no - internal helper utilities Platform Specific Features: N/A", "url": "https://github.com/envoyproxy/envoy/pull/46684", "createdAt": "2026-08-13T14:19:38Z", "updatedAt": "2026-08-13T16:00:32Z", "timestamp": "2026-08-13T16:00:32Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [], "author": "penguingao", "state": "closed", "assignees": [] }, { "id": "github:envoyproxy/envoy:pull_request:46685", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "Create Snapshot of runtime stats before incrementing counter", "text": "The stats_.load_success_ counter is incremented before the Snapshot of runtime metrics is taken. This leads to a small window where a client can request runtime metrics after load_success_ counter indicates a successful load but before the latest runtime metrics are available. Change-Id: Iac433fdf7637eec59186cfa44f2e065d367fc73f Commit Message: Additional Description: Risk Level: Testing: Docs Changes: Release Notes: Platform Specific Features: [Optional Runtime guard:] [Optional Fixes #Issue] [Optional Fixes commit #PR or SHA] [Optional Deprecated:] [Optional [API Considerations](https://github.com/envoyproxy/envoy/blob/main/api/review_checklist.md):]", "url": "https://github.com/envoyproxy/envoy/pull/46685", "createdAt": "2026-08-13T14:48:02Z", "updatedAt": "2026-08-13T14:49:08Z", "timestamp": "2026-08-13T14:49:08Z", "metrics": { "reactions": 0, "comments": 2 }, "labels": [], "author": "etruong42", "state": "open", "assignees": [] }, { "id": "github:envoyproxy/envoy:pull_request:46686", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "Add support for `serverNameOverride` in ALTS and create `ServerNameDecoratorTransportSocketOptions`", "text": "Commit Message: support `serverNameOverride` in ALTS and add `ServerNameDecoratingTransportSocketOptions` Additional Description: These two changes are in pursuit of eventually being able to pass the original target name to the TransportSocket 1) Create `ServerNameDecoratingTransportSocketOptions` as a `TransportSocketOptions` wrapper class that populates the `serverNameOverride` value. 2) Modify ALTS Transport Socket Options to use the `serverNameOverride` value and pass this `target_value` in to `StartHandshakeReq` Risk Level: Low (Creating decorator class in core network, and only new optional ALTS behavior with no-op defaults). Testing: `transport_socket_options_impl_test.cc` additions for `ServerNameDecoratingTransportSocketOptions`, `alts_proxy_test.cc`, `alts_tsi_handshaker_test.cc`, `tsi_socket_test.cc`, and `config_test.cc` for ALTS Transport Socket behavioral changes Docs Changes: n/a Release Notes: n/a Platform Specific Features: n/a", "url": "https://github.com/envoyproxy/envoy/pull/46686", "createdAt": "2026-08-13T16:56:41Z", "updatedAt": "2026-08-13T16:56:47Z", "timestamp": "2026-08-13T16:56:47Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [], "author": "MichaelHDing", "state": "open", "assignees": [] } ], "events": [ { "id": "event:8221c06d9f56f3a655a7", "signalId": "github:envoyproxy/envoy:pull_request:46308", "event": "discovered", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:envoyproxy/envoy:pull_request:46308", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "composite: fail over to the next sub-cluster when a sub-cluster has no hosts", "text": "## Commit Message composite: fail over to the next sub-cluster when a sub-cluster has no hosts The composite cluster failed a request with 503 no_healthy_upstream when the sub-cluster mapped to the current attempt had no host available, for example because DNS resolution returned an empty endpoint list or because all of its hosts had been ejected. Host selection now advances to the following sub-clusters in the configured list within the same attempt, and only fails when none of them can provide a host. Guarded by `envoy.reloadable_features.composite_cluster_skip_clusters_without_hosts`. ## Additional Description ### Documented behavior vs. actual behavior The `composite_cluster` [docs](https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/upstream/composite_cluster) stated: > *\"If a selected sub-cluster has no healthy hosts available, the request will fail according to that sub-cluster's load balancing behavior, **potentially triggering another retry attempt if configured**.\"* In practice that retry path was unreachable: `no_healthy_upstream` is a routing-level rejection raised before any upstream connection attempt, and no `retry_on` condition covers it. A composite cluster whose first sub-cluster had zero endpoints failed with `503 no_healthy_upstream` regardless of the retry policy, so per-request failover did not work at all in that scenario. ### Change from the previous revision of this PR The first revision of this PR added a core `no-healthy-upstream` retry condition (`RETRY_ON_NO_HEALTHY_UPSTREAM`) plus a hook in `Filter::createConnPoolOrHandleFailure()`. Per review feedback from @wbpcode and @agrawroh, that a core feature serving one extension is the wrong layer, and that the composite cluster should pick a sub-cluster that has healthy hosts itself. The previous approach has been fully reverted and the fix now lives entirely in the extension. Reverted back to `main`: `envoy/router/router.h`, `source/common/http/headers.h`, `source/common/router/retry_state_impl.{h,cc}`, `source/common/router/router.cc`, `test/common/router/{router_test,retry_state_impl_test}.cc`, `test/mocks/router/mocks.{h,cc}`, `api/envoy/config/route/v3/route_components.proto`, `docs/root/configuration/http/http_filters/router_filter.rst`. ### Fix `CompositeClusterLoadBalancer::chooseHost()` still maps the attempt count to a starting cluster index, but host selection now runs through a new `selectHostWithFailover()` helper that walks forward from that index: * A sub-cluster is skipped when it is not present in the cluster manager, or when its load balancer returns no host. * Selection returns immediately when a host is selected, or when the sub-cluster started asynchronous host selection (`HostSelectionResponse::cancelable` set), so an in-flight async selection is not abandoned or duplicated. * When no sub-cluster can provide a host, the `details` and `failure_status` of the last sub-cluster tried are propagated, so the resulting local reply keeps the same diagnostics as before. Availability is determined by asking the sub-cluster's load balancer rather than by inspecting its priority set, so nested composite/aggregate sub-clusters, `CLUSTER_PROVIDED` sub-clusters, panic mode and override-host behavior all keep working. When a sub-cluster can serve the attempt, its load balancer is the only one invoked, so there are no wasted host selections on the happy path. ### Behavior notes * Selection remains driven by the attempt count: an attempt that failed over to a later sub-cluster does not shift the mapping of subsequent attempts. With `[primary, secondary, fallback]` and an empty `primary`, attempt 1 uses `secondary` and attempt 2 also maps to `secondary`. This is documented in the arch overview. If reviewers prefer that a failover also advance the following attempts, that can be done by recording the used index in filter state — happy to add it here or as a follow-up. * `peekAnotherHost()` and `selectExistingConnection()` keep the plain attempt mapping. Every in-tree `selectExistingConnection()` implementation returns `nullopt`, so there is no practical mismatch, and prefetching does not need the failover. ### Minimal reproduction A minimal Docker Compose reproduction of the original bug is available at: https://github.com/JonSchaeffer/playground/tree/main/envoy/composite-bug-minimal-repro ## Risk Level Low — the change is scoped to the composite cluster extension, and it is behind a reloadable runtime guard. ## Testing * Unit tests in `test/extensions/clusters/composite/cluster_test.cc`: failover when the selected sub-cluster has no host, failover when the selected sub-cluster is missing from the cluster manager, no host plus preserved failure details when no sub-cluster can serve the request, asynchronous host selection returned without trying other sub-clusters, and legacy behavior with the runtime guard disabled. * Integration tests in `test/extensions/clusters/composite/cluster_integration_test.cc`: failover with `num_retries: 0` (proving no retry is involved), failover across two consecutive sub-clusters without endpoints, `503` when no sub-cluster has endpoints, and `503` with the runtime guard disabled. The two `no-healthy-upstream` retry tests from the previous revision were removed. * Format and spelling checks: `bazel run //tools/code_format:check_format` and `bazel run //tools/spelling:check_spelling_pedantic` both pass. ## Docs Changes * `docs/root/intro/arch_overview/upstream/composite_cluster.rst`: new \"Hosts availability\" section, updated the sub-cluster health / deterministic routing considerations, and documented the runtime guard and the attempt-progression caveat. * `api/envoy/extensions/clusters/composite/v3/cluster.proto`: comment-only update describing the failover. No field or type changes. ## Release Notes `changelogs/current/bug_fixes/composite_cluster__skip-clusters-without-hosts.rst`. ## Runtime guard `envoy.reloadable_features.composite_cluster_skip_clusters_without_hosts` (enabled by default). Setting it to `false` restores the previous behavior of failing the attempt when the sub-cluster mapped to that attempt has no host available. --- > **Note:** This PR was developed with AI assistance (Claude). The author has reviewed and > understands all changes.", "url": "https://github.com/envoyproxy/envoy/pull/46308", "createdAt": "2026-07-22T12:31:41Z", "updatedAt": "2026-08-13T13:45:04Z", "timestamp": "2026-08-13T13:45:04Z", "metrics": { "reactions": 0, "comments": 9 }, "labels": [ "api" ], "author": "JonSchaeffer", "state": "open", "assignees": [ "agrawroh", "wbpcode" ], "change": "new" } }, { "id": "event:b54eee24dc658bb8943e", "signalId": "github:envoyproxy/envoy:pull_request:43255", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:envoyproxy/envoy:pull_request:43255", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "[WIP] bazel: Add compatibility stubs for bzlmod", "text": "this provides some of the compatibility required for bzlmod, without breaking workspace mode will follow up to fully enable bzlmod (as non-default in subsequent pr)", "url": "https://github.com/envoyproxy/envoy/pull/43255", "createdAt": "2026-02-01T01:15:57Z", "updatedAt": "2026-08-13T13:41:03Z", "timestamp": "2026-08-13T13:41:03Z", "metrics": { "reactions": 0, "comments": 3 }, "labels": [ "no stalebot", "deps", "ai:assisted" ], "author": "phlax", "state": "open", "assignees": [ "RyanTheOptimist" ], "change": "updated" } }, { "id": "event:2449f00ddeb6a42416bf", "signalId": "github:envoyproxy/envoy:pull_request:46138", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:envoyproxy/envoy:pull_request:46138", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "add ratelimit descriptor extension to use jwt claims as descriptors", "text": "Commit Message: add ratelimit descriptor extension to use jwt claims as descriptors Additional Description: Adds a new rate limit descriptor extension that extracts jwt claims and uses it to rate limit. This is useful in cases where the actual JWT validation is done by the application but we want to apply rate limits based on jwt claims Risk Level: Low Testing: Docs Changes: Release Notes:", "url": "https://github.com/envoyproxy/envoy/pull/46138", "createdAt": "2026-07-15T06:07:55Z", "updatedAt": "2026-08-13T13:34:46Z", "timestamp": "2026-08-13T13:34:46Z", "metrics": { "reactions": 1, "comments": 11 }, "labels": [ "api" ], "author": "ramaraochavali", "state": "open", "assignees": [ "adisuissa" ], "change": "updated" } }, { "id": "event:81c0dfd8bc3d38d5e20c", "signalId": "github:envoyproxy/envoy:pull_request:46573", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:envoyproxy/envoy:pull_request:46573", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "Fix listFineGrainLoggers so that it lists loggers", "text": "Also add test to avoid regression Change-Id: I93d401aad43ea51a853725a8939f5b5524b3f8e1 Commit Message: Additional Description: Risk Level: Testing: Docs Changes: Release Notes: Platform Specific Features: [Optional Runtime guard:] [Optional Fixes #Issue] [Optional Fixes commit #PR or SHA] [Optional Deprecated:] [Optional [API Considerations](https://github.com/envoyproxy/envoy/blob/main/api/review_checklist.md):]", "url": "https://github.com/envoyproxy/envoy/pull/46573", "createdAt": "2026-08-07T13:37:05Z", "updatedAt": "2026-08-13T13:28:35Z", "timestamp": "2026-08-13T13:28:35Z", "metrics": { "reactions": 0, "comments": 3 }, "labels": [], "author": "etruong42", "state": "open", "assignees": [ "botengyao" ], "change": "updated" } }, { "id": "event:eba3f1721588f3dfc27c", "signalId": "github:envoyproxy/envoy:issue:28566", "event": "discovered", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:envoyproxy/envoy:issue:28566", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "issue", "title": "Shift `clang-tidy` to github action", "text": "Currently clang-tidy is not working very well and need some attention I am gradually picking off various bits of ci for shifting azp -> gh This one seems like quite a good candidate to start on the checks with.", "url": "https://github.com/envoyproxy/envoy/issues/28566", "createdAt": "2023-07-22T12:30:31Z", "updatedAt": "2026-08-13T13:25:10Z", "timestamp": "2026-08-13T13:25:10Z", "metrics": { "reactions": 0, "comments": 48 }, "labels": [ "no stalebot", "area/clang-tidy", "area/github-migration" ], "author": "phlax", "state": "open", "assignees": [ "jwendell" ], "change": "new" } }, { "id": "event:cf917ad6abfd81cc4c69", "signalId": "github:envoyproxy/envoy:pull_request:46545", "event": "discovered", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:envoyproxy/envoy:pull_request:46545", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "mcp_json_rest_bridge: track request status stats across filter code paths", "text": "Commit Message: mcp_json_rest_bridge: track request status stats across filter code paths Additional Description: This change instruments the `mcp_json_rest_bridge` filter to track request status statistics across all request and response processing code paths. Key details: - Added `incRequestCount()` helper to `McpJsonRestBridgeFilterConfig` using `scope_.counterFromStatNameWithTags()`. - Added request metrics tracking across local replies (`initialize`, `notifications/initialized`, `tools/list`), error responses (`sendErrorResponse`), streaming tool call headers (`encodeHeaders`), and backend responses (`setResponseMetadata`). - Populates `tool_name_` as the `mcp_param` tag **only after** tool validation succeeds to prevent metric cardinality explosion. - Consolidated stat counter assertions into primary request/response unit tests using a new `expectCounter` test helper. Risk Level: Low Testing: * Added unit tests in `config_test.cc` to verify counter is incremented with all/some of the tags. * Added integration tests to simulate multiple requests being aggregated in the counter. * Updated test fixtures in `mcp_json_rest_bridge_filter_test.cc` and `endpoint_keyed_filtering_test.cc` to pass `*stats_store_.rootScope()` to the config constructor. * Added unit test assertions covering all stat counter increments across filter request and response states in `mcp_json_rest_bridge_filter_test.cc`. * All test targets pass. Docs Changes: N/A Release Notes: N/A Platform Specific Features: N/A Runtime Guard: N/A Used AI to generate some of this code and I understand how it works.", "url": "https://github.com/envoyproxy/envoy/pull/46545", "createdAt": "2026-08-04T20:41:02Z", "updatedAt": "2026-08-13T13:16:27Z", "timestamp": "2026-08-13T13:16:27Z", "metrics": { "reactions": 0, "comments": 3 }, "labels": [ "waiting" ], "author": "nahurfonseca", "state": "open", "assignees": [ "mkbehr", "tyxia" ], "change": "new" } }, { "id": "event:1794d865fe21a361eb01", "signalId": "github:envoyproxy/envoy:pull_request:46683", "event": "discovered", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:envoyproxy/envoy:pull_request:46683", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "Use deterministic routes in load aware locality tests", "text": "Change-Id: Ie40b5278387dab7c2dea9e43416b68dbec9b1af0 Commit Message: Additional Description: Risk Level: Testing: Docs Changes: Release Notes: Platform Specific Features: [Optional Runtime guard:] [Optional Fixes #Issue] [Optional Fixes commit #PR or SHA] [Optional Deprecated:] [Optional [API Considerations](https://github.com/envoyproxy/envoy/blob/main/api/review_checklist.md):]", "url": "https://github.com/envoyproxy/envoy/pull/46683", "createdAt": "2026-08-13T13:14:57Z", "updatedAt": "2026-08-13T13:15:45Z", "timestamp": "2026-08-13T13:15:45Z", "metrics": { "reactions": 0, "comments": 2 }, "labels": [], "author": "etruong42", "state": "open", "assignees": [], "change": "new" } }, { "id": "event:adbe794373d2ebdaf9ff", "signalId": "github:envoyproxy/envoy:pull_request:46543", "event": "discovered", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:envoyproxy/envoy:pull_request:46543", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "mcp_transcoder: Fix Unbounded Recursion DoS", "text": "Commit Message: mcp_transcoder: Fix Unbounded Recursion DoS Additional Description: This PR limits the maximum nesting depth for JSON query parameter processing in constructQueryParams to 100, which mitigates a stack overflow condition caused by maliciously crafted, deeply nested query parameters. Risk Level: Low Testing: Unit tests. Docs Changes: N/A Release Notes: N/A Platform Specific Features: N/A", "url": "https://github.com/envoyproxy/envoy/pull/46543", "createdAt": "2026-08-04T19:18:20Z", "updatedAt": "2026-08-13T13:15:03Z", "timestamp": "2026-08-13T13:15:03Z", "metrics": { "reactions": 0, "comments": 5 }, "labels": [], "author": "guoyilin42", "state": "open", "assignees": [ "tyxia" ], "change": "new" } }, { "id": "event:0d223aed7dc914c3ceaf", "signalId": "github:envoyproxy/envoy:pull_request:46655", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:envoyproxy/envoy:pull_request:46655", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "filesystem: refactor win32 watcher_impl to use absl mutex and fix buffer alignment", "text": "Additional Description: Refactors the Win32 filesystem watcher (`WatcherImpl`): - Replaces `` (`concurrency::concurrent_queue`) with a thread-safe `ThreadSafeQueue` using `absl::Mutex`. This eliminates duplicate symbol link conflicts between `libc++` and MSVC `libconcrt.lib`. - Changes `DirectoryWatch` buffer type from `std::vector` to `std::vector` ensuring 4-byte DWORD alignment required by `ReadDirectoryChangesW` and `FILE_NOTIFY_INFORMATION`. - Synchronizes access to `DirectoryWatch::watches_` with an `absl::Mutex`. - Adds `callAndLogOnError` with exception handling and rate-limited logging. - Updates `watcher_impl_test.cc` to ensure file handles are cleanly closed before read events and flushes. Risk Level: medium (Win32 filesystem watcher refactor) Testing: `bazel test //test/common/filesystem:watcher_impl_test` Docs Changes: n/a Release Notes: Included under bug_fixes for Win32 watcher Platform Specific Features: Windows", "url": "https://github.com/envoyproxy/envoy/pull/46655", "createdAt": "2026-08-11T19:40:08Z", "updatedAt": "2026-08-13T13:11:30Z", "timestamp": "2026-08-13T13:11:30Z", "metrics": { "reactions": 0, "comments": 2 }, "labels": [ "waiting" ], "author": "citrus7", "state": "open", "assignees": [ "yanavlasov", "tyxia" ], "change": "updated" } }, { "id": "event:1520a1c3e6e86b99dab5", "signalId": "github:envoyproxy/envoy:pull_request:46502", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:envoyproxy/envoy:pull_request:46502", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "Support hot restart handoff for connectionless UDP flows", "text": "Commit Message: udp: Support hot restart handoff for connectionless UDP flows Additional Description: The parent instance keeps serving established UDP flows while draining and forwards packets of unknown flows to the child over the hot restart RPC, instead of going dark between drain start and parent shutdown. Risk Level: Medium Testing: Added unit and integration tests, manual Docs Changes: - Added `envoy.resource_limits.listener..udp_flow_limit`. - Added `downstream_flows_active, Gauge`, if equal to the limit, flows might get misrouted during hotrestart Release Notes: Added new_features entry Platform Specific Features: N/A Fixes #34732", "url": "https://github.com/envoyproxy/envoy/pull/46502", "createdAt": "2026-08-01T12:28:12Z", "updatedAt": "2026-08-13T13:03:38Z", "timestamp": "2026-08-13T13:03:38Z", "metrics": { "reactions": 0, "comments": 7 }, "labels": [ "api" ], "author": "filipcacky", "state": "open", "assignees": [ "nezdolik", "markdroth" ], "change": "updated" } }, { "id": "event:bad253d6c703fea5e565", "signalId": "github:envoyproxy/envoy:pull_request:45674", "event": "discovered", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:envoyproxy/envoy:pull_request:45674", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "hot restart: propagate programmatic stat tags across restart", "text": "**Commit Message:** hot restart: propagate programmatic stat tags across restart **Additional Description:** Stats created with programmatic tags (via `Scope::*FromStatNameWithTags` / the tag-aware `*FromTaggedName` API) embed their tag *values* into the flat stat name while keeping a clean `tagExtractedName` and a set of tags. This works on a fresh process, but breaks across a hot restart: - The parent serializes each counter/gauge to the child as **name string → value** only (`HotRestartingParent::Internal::exportStatsToChild`); `tags()` / `tagExtractedName()` are dropped. - The child's `StatMerger::mergeCounters` re-creates the stat from the name alone, which runs only regex tag extraction. With no matching `stats_tags` regex, the merged stat gets **empty tags** and `tagExtractedName == the full mangled name`. - That no-tags stat is created **before** the child's own code first touches the stat, so it wins the central-cache slot. The later tagged creation returns the already-mangled stat (stats are immutable post-creation). The tag values end up baked into the metric name with empty labels (e.g. as exported to Prometheus). This is the gap behind the long-standing `// TODO(snowp): Propagate tag values during hot restarts` in `stat_merger.cc`. Regex-extracted tags survive only because extraction re-derives them from the name; programmatic tags have nothing to re-derive from. This change actually propagates the tags: - `hot_restart.proto`: new `TaggedMetric` (tag-extracted name + repeated `Tag`) and `counter_tags` / `gauge_tags` maps on `Reply.Stats`. - The parent emits an entry **only for tags the child could not re-derive from the name**: it re-runs the store's `TagProducer` on the flat name and skips the stat when extraction reproduces the stored tags (the common case — including all default tag regexes). The stats transfer payload is therefore unchanged except for stats that actually carry programmatic tags. A nullable `Store::tagProducer()` accessor (default `nullptr`; only `ThreadLocalStoreImpl` overrides) supports the comparison. - The child decodes the metadata and `StatMerger` re-creates the stat with the original tags via new `Scope::counterFromMergedStatName` / `gaugeFromMergedStatName`. Following #45146 these have non-virtual-breaking defaults that delegate to the tag-aware `counterFromTaggedName` / `gaugeFromTaggedName` (which retain the metadata on tag-aware scopes and `IsolatedStoreImpl`); the legacy `ThreadLocalStore` `ScopeImpl` — which intentionally drops tag metadata on the `*FromTaggedName` path because it cannot compose tag-extracted names with its prefix in general — overrides them to honor the components, which arrive fully resolved. The full name is still reconstructed via `DynamicContext` (dynamic spans preserved), so the cache key matches the stat the child independently creates — the fix removes the first-write-wins poisoning rather than working around it. **Risk Level:** Medium — changes stats labels after a hot restart for tag-bearing stats. Runtime guarded. **Testing:** New tests: `stat_merger_test` (`ProgrammaticTagsSurviveMerge`, `ProgrammaticGaugeTagsSurviveMerge`, `ProgrammaticTagsLostWithoutMetadata` pinning the pre-fix symptom), `hot_restarting_parent_test` (`ExportsTagMetadataOnlyWhenNotRederivable`, `TagMetadataAppliedToMergedStats` end-to-end, `TagMetadataIgnoredWhenRuntimeFlagDisabled`), and `thread_local_store_test` (`MergedStatNameHonorsSuppliedTags` on both the legacy and tag-aware scopes). Built/run via RBE. **Docs Changes:** N/A **Release Notes:** Added (`changelogs/current/bug_fixes/stats__hot-restart-propagate-programmatic-stat-tags.rst`). **Runtime guard:** `envoy.reloadable_features.hot_restart_propagate_stat_tags` (revert to legacy name-derived behavior).", "url": "https://github.com/envoyproxy/envoy/pull/45674", "createdAt": "2026-06-16T23:12:06Z", "updatedAt": "2026-08-13T12:57:04Z", "timestamp": "2026-08-13T12:57:04Z", "metrics": { "reactions": 0, "comments": 14 }, "labels": [], "author": "bpalermo", "state": "open", "assignees": [ "wbpcode", "paul-r-gall" ], "change": "new" } }, { "id": "event:d53b78083781c073226f", "signalId": "github:envoyproxy/envoy:pull_request:46660", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:envoyproxy/envoy:pull_request:46660", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "tidy: enforce and apply C++20 container `contains()`", "text": "Enable the `readability-container-contains` clang-tidy check so that `count(k)`/`find(k) != end()` membership tests are flagged going forward, and apply the `.contains()` conversion across the non-extensions code (the extensions tree was cleaned up separately). Readability cleanup with no behavior change.", "url": "https://github.com/envoyproxy/envoy/pull/46660", "createdAt": "2026-08-12T02:12:42Z", "updatedAt": "2026-08-13T12:44:57Z", "timestamp": "2026-08-13T12:44:57Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "jwendell", "state": "closed", "assignees": [], "change": "updated" } }, { "id": "event:21faa199e45b79b57b1e", "signalId": "github:envoyproxy/envoy:pull_request:46549", "event": "discovered", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:envoyproxy/envoy:pull_request:46549", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "Using PassthroughState pointer as key for TLS baggage exchange", "text": " This pull request introduces a new mechanism for Istio peer_metadata filters sitting across an internal socket to exchange peer metadata information through thread local storage. The previous implementation would do it in two ways: - Legacy: the filters would exchange information \"in-wire\", through the byte stream. This cause problems as inner sockets for TLS and PROXY would break because of the modified payload. - Using downstream connection ID as a shared unique key between the filters so they can communicate through thread local storage. This also cause problems as the downstream connection ID might be duplicated in the same thread in some scenarios (when using HTTP2 mutiplexing requests). The new implementation will use a shared unique key based on the PassthroughState pointer, which is guaranteed to be unique for every internal socket connection. Commit Message: Additional Description: Risk Level: Testing: Docs Changes: Release Notes: Platform Specific Features: [Optional Runtime guard:] [Optional Fixes #Issue] [Optional Fixes commit #PR or SHA] [Optional Deprecated:] [Optional [API Considerations](https://github.com/envoyproxy/envoy/blob/main/api/review_checklist.md):]", "url": "https://github.com/envoyproxy/envoy/pull/46549", "createdAt": "2026-08-05T10:43:31Z", "updatedAt": "2026-08-13T12:34:32Z", "timestamp": "2026-08-13T12:34:32Z", "metrics": { "reactions": 0, "comments": 2 }, "labels": [ "waiting" ], "author": "grnmeira", "state": "open", "assignees": [ "krinkinmu", "kyessenov" ], "change": "new" } }, { "id": "event:6b5bc44b40701d7e36fe", "signalId": "github:envoyproxy/envoy:pull_request:46663", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:envoyproxy/envoy:pull_request:46663", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "cleanup: replace erase-remove idiom with std::erase_if or absl::erase_if", "text": "### Description Replace the traditional erase-remove idiom with the more concise `std::erase_if` and `absl::erase_if` APIs where applicable. This improves readability by expressing the intent to remove elements matching a predicate directly, while preserving the existing behavior. ### Changes Replace `std::remove_if` followed by `erase` with `std::erase_if` for standard containers. Replace the same pattern with `absl::erase_if` for supported Abseil containers. No functional behavior changes are intended.", "url": "https://github.com/envoyproxy/envoy/pull/46663", "createdAt": "2026-08-12T09:23:38Z", "updatedAt": "2026-08-13T12:27:44Z", "timestamp": "2026-08-13T12:27:44Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [], "author": "Amila-Rukshan", "state": "open", "assignees": [ "botengyao" ], "change": "updated" } }, { "id": "event:00dd8ca375683d230f46", "signalId": "github:envoyproxy/envoy:pull_request:46682", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:envoyproxy/envoy:pull_request:46682", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "Restrict local reply streaming integration tests", "text": "... so that it runs only on Envoy gRPC Change-Id: If3ff45c3ee9db39b14ed506a7ef85ae00ec7db24 Commit Message: Additional Description: Risk Level: Testing: Docs Changes: Release Notes: Platform Specific Features: [Optional Runtime guard:] [Optional Fixes #Issue] [Optional Fixes commit #PR or SHA] [Optional Deprecated:] [Optional [API Considerations](https://github.com/envoyproxy/envoy/blob/main/api/review_checklist.md):]", "url": "https://github.com/envoyproxy/envoy/pull/46682", "createdAt": "2026-08-13T12:13:50Z", "updatedAt": "2026-08-13T12:14:09Z", "timestamp": "2026-08-13T12:14:09Z", "metrics": { "reactions": 0, "comments": 2 }, "labels": [], "author": "etruong42", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:61814411b3a0b57d32b0", "signalId": "github:envoyproxy/envoy:pull_request:42890", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:envoyproxy/envoy:pull_request:42890", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "[WIP] bazel: Switch to bzlmod", "url": "https://github.com/envoyproxy/envoy/pull/42890", "createdAt": "2026-01-07T13:47:23Z", "updatedAt": "2026-08-13T11:32:30Z", "timestamp": "2026-08-13T11:32:30Z", "metrics": { "reactions": 0, "comments": 5 }, "labels": [ "no stalebot", "api", "v2-freeze", "deps", "workflows:untested" ], "author": "phlax", "state": "open", "assignees": [ "RyanTheOptimist" ], "change": "updated" } }, { "id": "event:352c203e4273224d09b1", "signalId": "github:envoyproxy/envoy:pull_request:46358", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:envoyproxy/envoy:pull_request:46358", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "redis: fix use-after-free and connection leak on cluster removal", "text": "Commit Message: redis: fix use-after-free and connection leak on cluster removal Additional Description: Each discovery client holds a shared_ptr back to the `RedisDiscoverySession` (as its client `Config`), so `~RedisCluster()` dropping its reference does not destroy the session while a discovery connection is open — the common steady state. The session then outlives the cluster with its resolve timer still armed, and the next fire dereferences the destroyed cluster. In-flight hostname resolutions (`CLUSTER SLOTS` entries that return hostnames, e.g. AWS ElastiCache) and zone-discovery `INFO` requests were never cancelled either. Cluster teardown now explicitly shuts the session down: it cancels the in-flight slot request, zone-discovery `INFO` requests and hostname resolutions (their `resolve()` handles are now tracked), disables the resolve timer, and closes the discovery connections (previously leaked). A session-owned `shutdown_` flag gates the entry points that can still reach the surviving session. All discovery work runs on the main thread, so the `is_destroying_` atomic is removed. Risk Level: low Testing: new unit tests (cluster destruction with held client config references, in-flight hostname resolution cancellation, in-flight zone-discovery `INFO` cancellation); existing redis_cluster_test suite green Docs Changes: n/a Release Notes: changelogs/current/bug_fixes/redis_proxy__cluster-destruction-use-after-free.rst Platform Specific Features: n/a", "url": "https://github.com/envoyproxy/envoy/pull/46358", "createdAt": "2026-07-23T23:38:36Z", "updatedAt": "2026-08-13T11:02:47Z", "timestamp": "2026-08-13T11:02:47Z", "metrics": { "reactions": 0, "comments": 3 }, "labels": [], "author": "bellatoris", "state": "open", "assignees": [ "nezdolik" ], "change": "updated" } }, { "id": "event:616ef9a8fc4c127e2411", "signalId": "github:envoyproxy/envoy:issue:46505", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:envoyproxy/envoy:issue:46505", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "issue", "title": "http1: unsafe ctype usage and size_t to int narrowing in the HTTP/1 parser", "text": "*Title*: http1: unsafe ctype usage and size_t to int narrowing in the HTTP/1 parser *Description*: Two type-safety defects in the HTTP/1 parser, found while working on #46496. Neither appears to be a security issue. There's no crash, no memory-safety consequence on supported platforms, and no reachable trigger for (2), so I'm raising publicly. Happy to move this to a security advisory if a maintainer disagrees. **1. ctype calls on raw `char` in `isUrlValid()`** - `balsa_parser.cc:114,120,139` `std::isalpha`/`isdigit`/`isalnum` require an argument representable as `unsigned char` or `EOF`. Where `char` is signed (x86-64 Linux), a request-target byte >= 0x80 arrives as a negative `int` which is undefined behaviour, and reachable from untrusted input: `isUrlValid()` is called from `OnRequestFirstLineInput()` (line 330), and line 114 runs before any range check, because line 105 only short-circuits targets beginning `/` or `*`. These functions are also locale-sensitive by contract. No impact in practice: glibc's ctype table is defined for -128..255, musl handles negatives, and Envoy never calls `setlocale`. `isVersionValid()` in the same file (line 164) already uses `absl::ascii_isdigit`. Switching the three sites to the `absl::ascii_*` equivalents is locale-independent and well-defined, and `absl/strings/ascii.h` is already included. Happy to send that PR. **2. `size_t` to `int` narrowing on the parse path** - `parser.h:121` `Parser::execute()` takes `int len`, but is fed `RawSlice::len_` (a `size_t`, `buffer.h:32`) via `dispatchSlice()` (`codec_impl.cc:668`). A slice above `INT_MAX` truncates negative; every guard in `BalsaParser::execute()` tests `> 0` or `== 0` (lines 217, 238, 245), so all are skipped and line 251 hands the negative value to `BalsaFrame::ProcessInput()`, where it widens to a large `size_t`. `LegacyHttpParserImpl` has the same shape (`legacy_parser_impl.cc:83,141`). The bound on the returned count in `codec_impl.cc` is a debug-only `ASSERT`. Envoy's read path never produces slices near 2 GB, so this is latent rather than triggerable. The fix touches `Parser`, `BalsaParser` and `LegacyHttpParserImpl` - worth a maintainer's view on scope before anyone writes it. [optional *Relevant Links*:] 1. https://github.com/envoyproxy/envoy/pull/46496 - the PR this was found alongside 2. https://en.cppreference.com/w/cpp/string/byte/isalpha - argument requirements for the ctype functions", "url": "https://github.com/envoyproxy/envoy/issues/46505", "createdAt": "2026-08-01T18:55:47Z", "updatedAt": "2026-08-13T10:42:05Z", "timestamp": "2026-08-13T10:42:05Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [ "bug", "area/http" ], "author": "guy-with-a-why", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:c9f5602c5a36a305d233", "signalId": "github:envoyproxy/envoy:issue:7468", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:envoyproxy/envoy:issue:7468", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "issue", "title": "Hot restart lead to the abnormal exit of the new process", "text": "*Title*: *Hot restart lead to the abnormal exit of the new process* *Description*: During the hot restart, the new Envoy process will start a timer to send `sendParentTerminateRequest` messages after taking over the traffic. but if the parent process quits early, can lead to ` sendParentTerminateRequest ` trigger RELEASE_ASSERT send failure, this kind of behavior is unacceptable, because the new process has already started to take over the traffic. ``` void DrainManagerImpl::startParentShutdownSequence() { ASSERT(!parent_shutdown_timer_); parent_shutdown_timer_ = server_.dispatcher().createTimer([this]() -> void { // Shut down the parent now. It should have already been draining. ENVOY_LOG(info, \"shutting down parent after drain\"); server_.hotRestart().sendParentTerminateRequest(); }); parent_shutdown_timer_->enableTimer(std::chrono::duration_cast( server_.options().parentShutdownTime())); } void HotRestartingChild::sendParentTerminateRequest() { if (restart_epoch_ == 0 || parent_terminated_) { return; } HotRestartMessage wrapped_request; wrapped_request.mutable_request()->mutable_terminate(); sendHotRestartMessage(parent_address_, wrapped_request); parent_terminated_ = true; // Once setting parent_terminated_ == true, we can send no more hot restart RPCs, and therefore // receive no more responses, including stats. So, now safe to forget our stat transferral state. // // This destruction is actually important far beyond memory efficiency. The scope-based temporary // counter logic relies on the StatMerger getting destroyed once hot restart's stat merging is // all done. (See stat_merger.h for details). stat_merger_.reset(); } void HotRestartingBase::sendHotRestartMessage(sockaddr_un& address, const HotRestartMessage& proto) { ...... const int rc = sendmsg(my_domain_socket_, &message, 0); RELEASE_ASSERT(rc == static_cast(cur_chunk_size), fmt::format(\"hot restart sendmsg() failed: returned {}, errno {}\", rc, errno)); } RELEASE_ASSERT(fcntl(my_domain_socket_, F_SETFL, O_NONBLOCK) != -1, fmt::format(\"Set domain socket nonblocking failed, errno = {}\", errno)); } ``` I think need to refactor ` sendHotRestartMessage `, send the results of the return, can be treated with the result of sending calls, rather than a unified RELEASE_ASSERT to deal with.", "url": "https://github.com/envoyproxy/envoy/issues/7468", "createdAt": "2019-07-04T07:00:40Z", "updatedAt": "2026-08-13T09:37:09Z", "timestamp": "2026-08-13T09:37:09Z", "metrics": { "reactions": 2, "comments": 4 }, "labels": [ "question" ], "author": "zyfjeff", "state": "closed", "assignees": [], "change": "updated" } }, { "id": "event:d3628e4e7bb3d350c644", "signalId": "github:envoyproxy/envoy:issue:46681", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:envoyproxy/envoy:issue:46681", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "issue", "title": "Newer release available `rules_shell`: v0.9.0 (current: v0.8.0)", "text": "Package Name: rules_shell@0.8.0 Current Version: v0.8.0@2026-04-15 Available Version: v0.9.0@2026-08-13 Upstream releases: https://github.com/bazelbuild/rules_shell/releases", "url": "https://github.com/envoyproxy/envoy/issues/46681", "createdAt": "2026-08-13T08:33:30Z", "updatedAt": "2026-08-13T08:33:30Z", "timestamp": "2026-08-13T08:33:30Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [ "area/build", "no stalebot", "dependencies" ], "author": "github-actions[bot]", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:7777542de11339b27c50", "signalId": "github:envoyproxy/envoy:issue:46680", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:envoyproxy/envoy:issue:46680", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "issue", "title": "Newer release available `dd_trace_cpp`: v2.2.0 (current: v2.1.1)", "text": "Package Name: dd_trace_cpp@2.1.1 Current Version: v2.1.1@2026-06-19 Available Version: v2.2.0@2026-08-12 Upstream releases: https://github.com/DataDog/dd-trace-cpp/releases", "url": "https://github.com/envoyproxy/envoy/issues/46680", "createdAt": "2026-08-13T08:33:29Z", "updatedAt": "2026-08-13T08:33:29Z", "timestamp": "2026-08-13T08:33:29Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [ "area/build", "no stalebot", "dependencies" ], "author": "github-actions[bot]", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:0dc92a7ba9ded2258aef", "signalId": "github:envoyproxy/envoy:pull_request:46679", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:envoyproxy/envoy:pull_request:46679", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "Add extension point to OpenTelemetry tracer for custom exporters.", "text": " ### Commit Message Added support for custom exporters in the OpenTelemetry tracer. In implementing this feature, I also changed some existing code in opentelemetry_tracer_impl.cc to make it more thread safe, such as moving the instantiation of the gRPC client factory out of the worker threads and into the main thread. This means that if the factory creation returns an error, it won't crash the worker thread, and thereby the whole Envoy proxy. ### Additional Description AI was used to generate the code and tests in this PR. I have reviewed – and fully understand – the code. ### Risk Level Low ### Testing I've added unit tests testing both the control plane and data plane code flows. ### Docs Changes None required ### Release Notes Added a changelog under new_features (area: tracing) ### Platform Specific Features None", "url": "https://github.com/envoyproxy/envoy/pull/46679", "createdAt": "2026-08-13T07:48:06Z", "updatedAt": "2026-08-13T08:30:05Z", "timestamp": "2026-08-13T08:30:05Z", "metrics": { "reactions": 0, "comments": 2 }, "labels": [ "api" ], "author": "jakebennert", "state": "open", "assignees": [ "mattklein123" ], "change": "updated" } }, { "id": "event:db3c4eebaba615a48517", "signalId": "github:envoyproxy/envoy:issue:46114", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:envoyproxy/envoy:issue:46114", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "issue", "title": "tls: share parsed CA trust store (X509_STORE) across contexts built from identical CA material", "text": "## Title tls: share parsed CA trust store (`X509_STORE`) across contexts built from identical CA material ## Problem Envoy builds a parsed CA trust store (`X509_STORE`) once per `Ssl::ContextImpl`, and a `ContextImpl` is created once per transport-socket factory — i.e. once per cluster, and again on every SDS rotation. When many clusters validate against the **same** CA bundle, Envoy re-parses that bundle (PEM → X509 → ASN.1) into a separate store per cluster. There is no content-addressed sharing, so memory grows with **(#clusters) × (CA bundle size)** instead of with the number of distinct CAs. This is the pathology Envoy already fixed for CRLs via `CrlCache`, never extended to the CA store. ## Why it happens - `ContextManagerImpl::createSslClientContext` never dedups by content — it builds a fresh `ClientContextImpl` every call (`context_manager_impl.cc:30`); `contexts_` is a pointer-keyed set for stats only. - Each `ContextImpl` allocates its own `SSL_CTX`/store (`context_impl.cc:107`), and the validator re-parses the CA into it with no cache lookup (`default_validator.cc:147-160`). - Sharing at SDS doesn't help: SDS dedups raw bytes by name (`secret_manager_impl.h:88`), but each subscribing factory still rebuilds a full store on load and rotation (`context_config_impl.cc:318`, `client_ssl_socket.cc:47`). ## Evidence Heap profiling of a gateway with many clusters sharing one corporate CA shows ~90% of the data-plane heap under upstream TLS validation: ``` Ssl::ClientContextImpl -> ContextImpl -> DefaultCertValidator -> BoringSSL PEM_X509_INFO_read / x_x509 / asn1 parsing -> malloc ``` Reducing worker concurrency doesn't lower it — confirming per-context, not per-worker, state. ## Impact Deployments with many backends behind a shared CA can use multiple GB at idle, scaling with cluster count rather than distinct-CA count. Common for gateways/meshes that emit one cluster per route destination, each referencing the same CA. ## Proposal Add a process-wide, content-addressed trust-store cache, modeled on the existing `CrlCache` (`default_validator.cc:52-93`), so contexts with identical CA material + store-affecting settings share one refcounted `X509_STORE`. ## Precedent `CrlCache` (`default_validator.cc:52-93`) is this exact pattern for CRLs — singleton, keyed on `SHA256(crl_pem)`, refcounted, `weak_ptr` eviction. Its doc comment (`default_validator.h:56-70`) describes this very problem (\"parsed and held in memory once per context\"). This generalizes it to the CA store.", "url": "https://github.com/envoyproxy/envoy/issues/46114", "createdAt": "2026-07-14T08:11:13Z", "updatedAt": "2026-08-13T08:27:33Z", "timestamp": "2026-08-13T08:27:33Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [ "stale" ], "author": "zhaohuabing", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:7cb02f879d925046cc96", "signalId": "github:envoyproxy/envoy:pull_request:46113", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:envoyproxy/envoy:pull_request:46113", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "build(deps): bump mypy from 1.20.2 to 2.3.0 in /mobile/tools/python", "text": "Bumps [mypy](https://github.com/python/mypy) from 1.20.2 to 2.3.0.
Changelog

Sourced from mypy's changelog.

Mypy Release Notes

Next Release

Packaging changes

Mypy 2.3

We've just uploaded mypy 2.3.0 to the Python Package Index (PyPI). Mypy is a static type checker for Python. This release includes new features, performance improvements and bug fixes. You can install it as follows:

python3 -m pip install -U mypy

You can read the full documentation for this release on Read the Docs.

The Upcoming Switch to the New Native Parser

We are planning to enable the new native parser (--native-parser) by default soon. We recommend that you test the native parser in your projects and report any issues in the mypy issue tracker.

Mypyc Free-threading Memory Safety

Free-threaded Python builds that don't have the GIL require additional synchronization primitives or lock-free algorithms to ensure memory safety when there are race conditions (for example, when a thread reads a list item while another thread writes the same list item concurrently). This release greatly improves memory safety of free threading.

List operations are now memory-safe on free threaded Python builds, even in the presence of race conditions. This has some performance cost. For list-heavy workloads, using librt.vecs.vec instead of list is often significantly faster, but note that vec is not (and likely won't be) fully memory safe, and the user is expected to avoid race conditions. The newly introduced librt.threading.Lock helps with this. Using variable-length tuples can also be more efficient than lists, since tuples are immutable and don't require expensive synchronization to ensure memory safety.

Instance attribute access is also (mostly) memory safe now on free-threaded builds in the presence of race conditions. We are planning to fix the remaining unsafe cases in a future release.

Full list of changes:

  • Make attribute access memory safe on free-threaded builds (Jukka Lehtosalo, PR 21705)
  • Fix unsafe borrowing of instance attributes with free-threading (Jukka Lehtosalo, PR 21688)
  • Make list get/set item more memory safe on free-threaded builds (Jukka Lehtosalo, PR 21683)
  • Don't borrow list items on free-threaded builds (Jukka Lehtosalo, PR 21679)
  • Make multiple assignment from list memory-safe on free-threaded builds (Jukka Lehtosalo, PR 21684)

... (truncated)

Commits
  • 8aabf84 Drop +dev from version
  • 4d8ad2a Update changelog for 2.3 release (#21728)
  • 2c21546 [mypyc] Update documentation of race conditions under free threading (#21726)
  • a9f62a3 [mypyc] Make attribute access memory safe on free-threaded builds (#21705)
  • 0faa413 Use PYODIDE environment variable for Emscripten cross-compilation detection...
  • 3d75cdb [mypyc] Borrow final attributes more aggressively (#21702)
  • 24c237d [mypyc] Improve documentation of Final (#21713)
  • b5be217 [mypyc] Update free threading Python compatibility docs (#21711)
  • cbcb51a Narrow for frozendict membership check (#21709)
  • af2bc0f Sync typeshed (#21707)
  • Additional commits viewable in compare view

[![Dependabot compatibility score](https://dependabot-badges.githubapp.com/badges/compatibility_score?dependency-name=mypy&package-manager=pip&previous-version=1.20.2&new-version=2.3.0)](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) ---
Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot show ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
", "url": "https://github.com/envoyproxy/envoy/pull/46113", "createdAt": "2026-07-14T06:06:32Z", "updatedAt": "2026-08-13T08:27:31Z", "timestamp": "2026-08-13T08:27:31Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [ "stale", "dependencies", "python" ], "author": "dependabot[bot]", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:b522cd3c0da5e1cd7796", "signalId": "github:envoyproxy/envoy:issue:41065", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:envoyproxy/envoy:issue:41065", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "issue", "title": "Add Support for JA4Latency FingerPrint Hash", "text": "*Title*: *One line description* *Description*: >Describe the desired behavior, what scenario it enables and how it would be used. Envoy Proxy supports JA3 and JA4 Fingerprint Hashes today https://www.envoyproxy.io/docs/envoy/latest/api-v3/extensions/filters/listener/tls_inspector/v3/tls_inspector.proto.html#extensions-filters-listener-tls-inspector-v3-tlsinspector Would be great to also support JA4Latency https://blog.foxio.io/ja4+-network-fingerprinting which helps understand client locality useful from a security perspective [optional *Relevant Links*:] >Any extra documentation required to understand the issue.", "url": "https://github.com/envoyproxy/envoy/issues/41065", "createdAt": "2025-09-12T16:28:40Z", "updatedAt": "2026-08-13T08:27:23Z", "timestamp": "2026-08-13T08:27:23Z", "metrics": { "reactions": 1, "comments": 10 }, "labels": [ "enhancement", "area/tls", "stale", "area/tls_inspector" ], "author": "arkodg", "state": "closed", "assignees": [ "agrawroh" ], "change": "updated" } }, { "id": "event:8416378d3d36bc3d1746", "signalId": "github:envoyproxy/envoy:issue:46677", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:envoyproxy/envoy:issue:46677", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "issue", "title": "reverse_tunnel: Implement proactive pings from the downstream_socket_interface", "text": "*Title*: reverse_tunnel: Implement proactive pings from the downstream_socket_interface *Description*: Currently the downstream_socket_interface does not proactive ping the upstream side using the RPING mechanism -> it only responds to pings this makes the downstream side invisible to reachability. Worse if the network falls through the downstream never detects it while the upstream thinks the connection is gone. This could have prevented issues like [this](https://github.com/envoyproxy/envoy/pull/46556). Expectation here is to implement http2 style ping and pong frames and have keepalive duration and timeout before the socket is upgraded to http2 for such detections from both ends.", "url": "https://github.com/envoyproxy/envoy/issues/46677", "createdAt": "2026-08-13T04:33:56Z", "updatedAt": "2026-08-13T08:22:42Z", "timestamp": "2026-08-13T08:22:42Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [ "enhancement", "no stalebot", "area/reverse_tunnels" ], "author": "aakugan", "state": "open", "assignees": [ "aakugan" ], "change": "updated" } }, { "id": "event:c2721530b86dc4df0b4d", "signalId": "github:envoyproxy/envoy:pull_request:43771", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:envoyproxy/envoy:pull_request:43771", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "Manage on-call rotation and ical generation in code", "text": "Commit Message: Manage on-call rotation and ical generation in code Additional Description: Our dependency on opsgenie appears to have run its course - our notifications keep drifting out of sync, the calendar isn't working very well, and we don't have enough seats to even have the scheduling be correct. These scripts should make it fairly easy to manage the oncall rotation through code, without need for external accounts. The generated ical calendar is required to be up-to-date by a `py_test` target that will fail if changes are not kept synchronized, keeping us from accidentally drifting out of sync. Removing people from the rotation should be cleaner with this script, as it makes a concerted effort to minimize schedule disruption - the goal is to keep schedule changes at least 2 months in the future (provided someone is willing to volunteer to substitute for one shift for a removed person - if not, there is a `dirty` option to allow schedules to be disrupted.) followups TODO: - [ ] update `GOVERNANCE.md` (search \"opsgenie\") to instead reference the new ical. - [ ] Update the google calendar to source from the new ical. - [ ] Update `tools/repo/notify.py` to source from the helper library. Risk Level: None, doesn't change anything currently active. Testing: Manually validated adding and each of the variations of removing, ensuring that the ical file was updated appropriately in each case. Docs Changes: Just the included README.md. Release Notes: n/a Platform Specific Features: n/a", "url": "https://github.com/envoyproxy/envoy/pull/43771", "createdAt": "2026-03-04T20:18:05Z", "updatedAt": "2026-08-13T08:17:46Z", "timestamp": "2026-08-13T08:17:46Z", "metrics": { "reactions": 0, "comments": 13 }, "labels": [ "no stalebot", "waiting" ], "author": "ravenblackx", "state": "open", "assignees": [ "phlax" ], "change": "updated" } }, { "id": "event:2c0243b2b7022d1e3e03", "signalId": "github:envoyproxy/envoy:pull_request:46667", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:envoyproxy/envoy:pull_request:46667", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "fix: health check probes blocked indefinitely when EDS initialFetchTimeout is 0s", "text": "_Commit Message:_ when a cluster is configured with EDS and initialFetchTimeout: 0s, the cluster stays in warming state indefinitely until EDS delivers its first response, no timeout fires to unblock it. _Additional Description:_ added a bypass in ClusterImplBase::setHealthChecker(). when health_check_after_cluster_warming is enabled, health checks are still started immediately if both conditions hold: 1. the EDS config source has initialFetchTimeout: 0s (hasZeroInitialFetchTimeout() == true) 2. there are no pending SDS init targets (init_manager_.uninitializedCount() == 0) _Risk Level:_ Low _Testing:_ Will be added soon. _Release Notes:_ fix health check probes being blocked indefinitely on EDS clusters configured with initialFetchTimeout: 0s. With health_check_after_cluster_warming enabled(default), health checks are no longer deferred when EDS warming has no timeout deadline. Fixes #46666", "url": "https://github.com/envoyproxy/envoy/pull/46667", "createdAt": "2026-08-12T15:33:25Z", "updatedAt": "2026-08-13T08:06:21Z", "timestamp": "2026-08-13T08:06:21Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [], "author": "yuehaii", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:4302a38e5f3d8bdd0f3b", "signalId": "github:envoyproxy/envoy:issue:46584", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:envoyproxy/envoy:issue:46584", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "issue", "title": "http2: allow configuring upstream headers as HPACK never indexed", "text": "*Title*: http2: allow configuring upstream headers as HPACK never indexed *Description*: Envoy should allow operators to configure HTTP/2 request headers to use HPACK's \"Literal Header Field Never Indexed\" representation when forwarding requests to an upstream. This is useful for high-cardinality values such as request IDs, trace IDs, or per-request tokens. These values are unlikely to be reused, so adding them to the dynamic HPACK table provides little compression benefit while causing unnecessary insertions, lookups, and evictions. Marking them as never indexed avoids this table churn and can reduce CPU usage in Envoy and the upstream HTTP/2 decoder. Envoy terminates the downstream HTTP/2 connection and creates a separate upstream HTTP/2 connection. Therefore, the client's HPACK indexing decision cannot be preserved automatically. Envoy must apply the configured policy when it re-encodes the headers for the upstream connection. Example configuration: ```yaml static_resources: clusters: - name: upstream connect_timeout: 2s type: STRICT_DNS load_assignment: cluster_name: upstream endpoints: - lb_endpoints: - endpoint: address: socket_address: address: upstream.example.com port_value: 8080 typed_extension_protocol_options: envoy.extensions.upstreams.http.v3.HttpProtocolOptions: \"@type\": type.googleapis.com/envoy.extensions.upstreams.http.v3.HttpProtocolOptions explicit_http_config: http2_protocol_options: headers_to_never_index: - x-request-id - x-trace-id - x-high-cardinality-token ``` Configured headers are forwarded unchanged, but their upstream HTTP/2 header fields are encoded using the never-indexed representation. Headers not listed in the configuration retain their existing HPACK indexing behavior. *Relevant Links*: - [POC Implementation branch](https://github.com/petedmarsh/envoy/tree/http2-never-index-headers) - [RFC 7541 section 6.2.3: Literal Header Field Never Indexed](https://www.rfc-editor.org/rfc/rfc7541#section-6.2.3) The POC implementation branch was generated by OpenAI Codex using GPT-5. It works and improves both cpu and bytes transferred in my benchmarks, but I am not a C++ programmer so I cannot vouch for the code. It is a POC/example only.", "url": "https://github.com/envoyproxy/envoy/issues/46584", "createdAt": "2026-08-07T22:45:58Z", "updatedAt": "2026-08-13T07:01:53Z", "timestamp": "2026-08-13T07:01:53Z", "metrics": { "reactions": 0, "comments": 3 }, "labels": [ "enhancement", "area/http" ], "author": "petedmarsh", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:03fe32aafc7fdfac2d75", "signalId": "github:envoyproxy/envoy:issue:46678", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:envoyproxy/envoy:issue:46678", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "issue", "title": "quic Support With OpenSSL", "text": "*Title*: *One line description* Support QUIC when Envoy is compiled with OpenSSL support enabled. *Description*: Desired Behaviour: Envoy when compiled with OpenSSL, should be able to serve quic based requests.", "url": "https://github.com/envoyproxy/envoy/issues/46678", "createdAt": "2026-08-13T06:32:03Z", "updatedAt": "2026-08-13T06:32:03Z", "timestamp": "2026-08-13T06:32:03Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [ "enhancement", "triage" ], "author": "Sukhdev841", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:2f950236d1f3f59bdc37", "signalId": "github:envoyproxy/envoy:pull_request:46006", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:envoyproxy/envoy:pull_request:46006", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "test: fix flaky xds_failover StartupPrimaryNotResponding for GoogleGrpc TRANSIENT_FAILURE", "text": "`XdsFailoverAdsIntegrationTest.StartupPrimaryNotResponding/15` (IPv6, GoogleGrpc, UnifiedDelta) fails intermittently under ASAN due to a race between gRPC's real-time channel backoff and Envoy's simulated-time retry timer. ## Root cause After the first `primaryConnectionFailure()` closes the TCP connection, the gRPC channel enters `TRANSIENT_FAILURE` with a ~1s real-time backoff. `waitForPrimaryXdsRetryTimer()` advances **simulated** time, firing Envoy's retry timer before that real-time backoff expires. The gRPC library immediately rejects the `establishNewStream()` attempt (no TCP connection made), which counts as the 2nd consecutive failure and triggers failover. The test's second `primaryConnectionFailure()` then waits 30s (ASAN `DefaultTimeout`) for a primary TCP connection that never arrives — Envoy has already switched to failover — hitting the `RELEASE_ASSERT`. This race is timing-sensitive: for IPv4 the gRPC library fast-retries before `onEstablishmentFailure` fires (channel stays in `CONNECTING`), so the race doesn't manifest there. ## Fix In `StartupPrimaryNotResponding`, before the second `primaryConnectionFailure()` call, poll (real-time only, **no** simulated clock advancement) for `cds.update_failure ≥ 2` within `200×TIMEOUT_FACTOR` ms. If the counter reaches 2, the 2nd failure already occurred via `TRANSIENT_FAILURE` and the explicit TCP-close step is skipped: ```cpp bool second_failure_via_transient_failure = false; if (clientType() == Grpc::ClientType::GoogleGrpc) { const auto deadline = absl::Now() + absl::Milliseconds(200 * TIMEOUT_FACTOR); constexpr absl::Duration kPollInterval = absl::Milliseconds(5); while (absl::Now() < deadline) { const auto counter = TestUtility::findCounter( test_server_->statStore(), \"cluster_manager.cds.update_failure\"); if (counter != nullptr && counter->value() >= 2) { second_failure_via_transient_failure = true; break; } absl::SleepFor(kPollInterval); } } if (!second_failure_via_transient_failure) { primaryConnectionFailure(); ASSERT_TRUE(xds_connection_->waitForDisconnect()); } ``` Polling uses real time (not `advanceTimeWait`) to avoid firing additional simulated timers that could interfere with test state. The `200×TIMEOUT_FACTOR` window is well above the typical <60ms propagation latency for the gRPC completion queue → Envoy main thread path. ## Files changed - **`test/extensions/config_subscription/grpc/xds_failover_integration_test.cc`** — TRANSIENT_FAILURE detection + `absl/time` includes - **`test/extensions/config_subscription/grpc/BUILD`** — added `@abseil-cpp//absl/time` dep", "url": "https://github.com/envoyproxy/envoy/pull/46006", "createdAt": "2026-07-06T23:11:54Z", "updatedAt": "2026-08-13T04:32:57Z", "timestamp": "2026-08-13T04:32:57Z", "metrics": { "reactions": 0, "comments": 3 }, "labels": [ "stale" ], "author": "Copilot", "state": "closed", "assignees": [ "yanavlasov", "Copilot" ], "change": "updated" } }, { "id": "event:59aea99ae3ba35e5f42b", "signalId": "github:envoyproxy/envoy:pull_request:46670", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:envoyproxy/envoy:pull_request:46670", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "load_aware_locality: add out-of-band ORCA reporting", "text": "Commit Message: implement out-of-band ORCA reporting for load_aware_locality Additional Description: Follow-up to https://github.com/envoyproxy/envoy/pull/45725 to wire up ORCA out-of-band reporting with the additional below changes: - Adds oob_reporting_config proto field - Graduates envoy.load_balancing_policies.load_aware_locality from `wip` to `alpha` in extensions_metadata.yaml. - Fixes `lb_orca_oob.active_sessions` accounting in the shared OrcaOobManager Risk Level: Low - still an alpha marked policy and opt-in only Testing: Added end-to-end OOB integration test and other coverage Docs Changes: Yes Release Notes: Updated existing (still unreleased) Platform Specific Features: N/A xRef https://github.com/envoyproxy/envoy/issues/43665 xRef https://github.com/envoyproxy/envoy/issues/6614", "url": "https://github.com/envoyproxy/envoy/pull/46670", "createdAt": "2026-08-12T17:29:45Z", "updatedAt": "2026-08-13T04:22:17Z", "timestamp": "2026-08-13T04:22:17Z", "metrics": { "reactions": 0, "comments": 5 }, "labels": [ "api" ], "author": "jukie", "state": "open", "assignees": [ "markdroth" ], "change": "updated" } }, { "id": "event:8ce36e1b7bc0032a76bd", "signalId": "github:envoyproxy/envoy:pull_request:46664", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:envoyproxy/envoy:pull_request:46664", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "rds: make the init manager for rds works for filter_chain and oauth2", "text": "Commit Message: rds: make the init manager for rds works for filter_chain and oauth2 Additional Description: Now, all configuration on the route could optionally add an async warming target to the route level init manager. The change of oauth2 showed how it works. Risk Level: n/a. Testing: unit. Docs Changes: n/a. Release Notes: added. Platform Specific Features: n/a.", "url": "https://github.com/envoyproxy/envoy/pull/46664", "createdAt": "2026-08-12T09:51:11Z", "updatedAt": "2026-08-13T03:25:33Z", "timestamp": "2026-08-13T03:25:33Z", "metrics": { "reactions": 0, "comments": 5 }, "labels": [], "author": "wbpcode", "state": "open", "assignees": [ "htuch" ], "change": "updated" } }, { "id": "event:472650ca15d399d309f1", "signalId": "github:envoyproxy/envoy:pull_request:46560", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:envoyproxy/envoy:pull_request:46560", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "Avoid excessive hashing for well-known header lookups", "text": " Commit Message: Additional Description: Risk Level: Testing: Docs Changes: Release Notes: Platform Specific Features: [Optional Runtime guard:] [Optional Fixes #Issue] [Optional Fixes commit #PR or SHA] [Optional Deprecated:] [Optional [API Considerations](https://github.com/envoyproxy/envoy/blob/main/api/review_checklist.md):]", "url": "https://github.com/envoyproxy/envoy/pull/46560", "createdAt": "2026-08-06T14:24:17Z", "updatedAt": "2026-08-13T02:03:13Z", "timestamp": "2026-08-13T02:03:13Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [], "author": "etruong42", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:3e3574264ffde5021d56", "signalId": "github:envoyproxy/envoy:pull_request:46656", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:envoyproxy/envoy:pull_request:46656", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "Avoid unnecesary renaming of watcher_target.yaml", "text": "This avoids the race condition where watcher_target.yaml is not present Change-Id: I7f8c67023ac31f3a9cac294caca5c0d18c30ee1d Commit Message: Additional Description: Risk Level: Testing: Docs Changes: Release Notes: Platform Specific Features: [Optional Runtime guard:] [Optional Fixes #Issue] [Optional Fixes commit #PR or SHA] [Optional Deprecated:] [Optional [API Considerations](https://github.com/envoyproxy/envoy/blob/main/api/review_checklist.md):]", "url": "https://github.com/envoyproxy/envoy/pull/46656", "createdAt": "2026-08-11T19:50:47Z", "updatedAt": "2026-08-13T01:59:51Z", "timestamp": "2026-08-13T01:59:51Z", "metrics": { "reactions": 0, "comments": 3 }, "labels": [], "author": "etruong42", "state": "open", "assignees": [ "phlax" ], "change": "updated" } }, { "id": "event:237382e38a9666247ef7", "signalId": "github:envoyproxy/envoy:pull_request:46676", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:envoyproxy/envoy:pull_request:46676", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "Allow connection teardown even when cert selection is not yet complete", "text": "https://github.com/envoyproxy/envoy/pull/45755 allowed the socket state to transition to `ShutdownSent` before cert selection is complete (as intended). However, this could cause `ENVOY_BUG` to be thrown when `SslSocket::onAsynchronousCertificateSelectionComplete()` is invoked. This patch updates `SslSocket::onAsynchronousCertificateSelectionComplete` to allow this socket state which is consistent with the implementation of `SslSocket::onAsynchronousCertValidationComplete`. Change-Id: I155b874accd54affa65bfa0b744ff99154060570 Commit Message: Additional Description: Risk Level: Testing: Docs Changes: Release Notes: Platform Specific Features: [Optional Runtime guard:] [Optional Fixes #Issue] [Optional Fixes commit #PR or SHA] [Optional Deprecated:] [Optional [API Considerations](https://github.com/envoyproxy/envoy/blob/main/api/review_checklist.md):]", "url": "https://github.com/envoyproxy/envoy/pull/46676", "createdAt": "2026-08-13T01:58:15Z", "updatedAt": "2026-08-13T12:55:38Z", "timestamp": "2026-08-13T12:55:38Z", "metrics": { "reactions": 0, "comments": 2 }, "labels": [], "author": "etruong42", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:d7adf672778805992bf9", "signalId": "github:envoyproxy/envoy:pull_request:46558", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:envoyproxy/envoy:pull_request:46558", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "ext_proc: document session affinity configuration", "text": "Commit Message: ext_proc: document session affinity configuration Additional Description: Documents the existing configuration path for keeping requests with the same session key on one external processor endpoint. The downstream key is copied into Envoy gRPC initial metadata and used by a matching cluster-level hash policy. Adds integration coverage for header affinity, passive-cookie affinity, and requests without an affinity key. No production behavior changes are introduced. A runnable Go demonstration is available at https://github.com/dio/ext-proc-session-affinity. AI assistance was used to help prepare the documentation and tests; the submitter reviewed and validated the resulting change. Risk Level: Low Testing: Focused ext_proc integration test. The runnable demo also measured header and passive-cookie affinity across 32 sessions and 160 requests per mode, with both processor endpoints observed and zero affinity violations. Docs Changes: Adds ext_proc session-affinity configuration guidance and examples. Release Notes: N/A Platform Specific Features: N/A Fixes #46159", "url": "https://github.com/envoyproxy/envoy/pull/46558", "createdAt": "2026-08-06T07:34:50Z", "updatedAt": "2026-08-13T00:38:52Z", "timestamp": "2026-08-13T00:38:52Z", "metrics": { "reactions": 0, "comments": 6 }, "labels": [], "author": "dio", "state": "closed", "assignees": [ "phlax", "tyxia", "yanjunxiang-google" ], "change": "updated" } }, { "id": "event:b181ec29d45c516c020d", "signalId": "github:envoyproxy/envoy:issue:46104", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:envoyproxy/envoy:issue:46104", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "issue", "title": "openssl compat: implement CNSA1_202603 compliance policy", "text": "## Description The OpenSSL compat layer does not implement the `ssl_compliance_policy_cnsa1_202603` case in `SSL_CTX_set_compliance_policy`. When a user configures CNSA1 on an Envoy build using OpenSSL, the TLS context creation fails and Envoy refuses to start. BoringSSL implements CNSA1 natively via `SSL_CTX_set_compliance_policy(ssl_compliance_policy_cnsa1_202603)`, which configures: - TLS 1.2 or TLS 1.3 - For TLS 1.2, only `TLS_ECDHE_[ECDSA|RSA]_WITH_AES_256_GCM_SHA384` - For TLS 1.3, only AES-256-GCM - ML-KEM-1024 or P-384 for key agreement, preferring ML-KEM-1024 - For handshake signatures, only ECDSA with P-384/SHA-384 or RSA with SHA-384 ## What's needed A full implementation in the compat layer requires: 1. **ML-KEM-1024 TLS group support** — OpenSSL 3.5+ supports ML-KEM-1024 as a cryptographic primitive and has hybrid groups like `SecP384r1MLKEM1024`, but the compat layer has the group mappings commented out (`ossl_NID_MLKEM1024`). These need to be enabled and tested first. 2. **TLS 1.3 ciphersuite restriction** — The compat layer needs to restrict TLS 1.3 to AES-256-GCM only (via `SSL_CTX_set_ciphersuites` in OpenSSL). 3. **Signature algorithm and key agreement configuration** — P-384 group, SHA-384 signature algorithms, and server cipher preference. These are straightforward using existing compat layer patterns. ## Context - CNSA1 support was added to Envoy in #46089 - The compat layer currently returns 0 (unsupported) for this policy, which is the correct behavior until a full implementation is available - Relevant file: `compat/openssl/source/SSL_CTX_set_compliance_policy.cc`", "url": "https://github.com/envoyproxy/envoy/issues/46104", "createdAt": "2026-07-13T19:44:39Z", "updatedAt": "2026-08-13T00:12:48Z", "timestamp": "2026-08-13T00:12:48Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [ "area/tls", "stale" ], "author": "jwendell", "state": "open", "assignees": [ "jwendell" ], "change": "updated" } }, { "id": "event:14a68455d228d2b13a91", "signalId": "github:envoyproxy/envoy:pull_request:46675", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:envoyproxy/envoy:pull_request:46675", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "transport_socket(http_11_proxy): add Proxy-Authorization header support", "text": "Commit Message: This patch adds support in HTTP/1.1 Proxy for HTTP proxy authorization. The HTTP/1.1 Proxy looks up the encoded credentials in its host's typed filter metadata and sends it with the Proxy-Authorization HTTP header in the CONNECT request to the proxy. Proxy authorization is still unsupported when filter state metadata is used. Additional Description: AI used to write tests Risk Level: Low Testing: Unit and integration test added Docs Changes: No Release Notes: Platform Specific Features: No", "url": "https://github.com/envoyproxy/envoy/pull/46675", "createdAt": "2026-08-12T23:30:17Z", "updatedAt": "2026-08-12T23:53:10Z", "timestamp": "2026-08-12T23:53:10Z", "metrics": { "reactions": 0, "comments": 2 }, "labels": [], "author": "glennc24", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:fad2c3ad9bc1bc3a3cc0", "signalId": "github:envoyproxy/envoy:pull_request:46668", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:envoyproxy/envoy:pull_request:46668", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "Rescope Logger::Levels enum so it can be moved to envoy/ directory", "text": "The main change is in the source/common/common/base_logger.h, moving the Levels enum out of the Logger class into the outer Logger namespace. This is intermediate step to using this enum in Envoy's interfaces in the envoy/ directory. This will prevent leaking of the spdlog dependency to proprietary components that need to manipulate Envoy's log level programmatically. Risk Level: low Testing: unit tests Docs Changes: no Release Notes: no Platform Specific Features: no", "url": "https://github.com/envoyproxy/envoy/pull/46668", "createdAt": "2026-08-12T15:37:40Z", "updatedAt": "2026-08-12T23:13:51Z", "timestamp": "2026-08-12T23:13:51Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [], "author": "yanavlasov", "state": "closed", "assignees": [], "change": "updated" } }, { "id": "event:223278e0998c3765a807", "signalId": "github:envoyproxy/envoy:pull_request:45882", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:envoyproxy/envoy:pull_request:45882", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "hot_restart: fix integer overflow in IPC message length handling", "text": "Description: The hot restart IPC protocol reads a uint64_t message length from the first 8 bytes of an incoming datagram and uses it to compute the required receive buffer size. When expected_proto_length_ is close to UINT64_MAX, adding sizeof(uint64_t) may wrap around due to unsigned integer overflow, producing an invalid buffer size value. Add an explicit overflow check before resizing the receive buffer, matching existing overflow-detection patterns used elsewhere in the Envoy codebase. Also adds unit tests covering overflow edge cases and normal message processing. Risk Level: Low Testing: * Added unit tests for UINT64_MAX * Added unit tests for UINT64_MAX - 7 * Added unit tests for normal-length messages Docs Changes: N/A Release Notes: Included Fixes #45872", "url": "https://github.com/envoyproxy/envoy/pull/45882", "createdAt": "2026-06-29T14:33:54Z", "updatedAt": "2026-08-12T23:04:13Z", "timestamp": "2026-08-12T23:04:13Z", "metrics": { "reactions": 0, "comments": 5 }, "labels": [ "stale", "waiting" ], "author": "ghaithabdulreda", "state": "closed", "assignees": [ "yanavlasov" ], "change": "updated" } }, { "id": "event:f6e7452a10cd565fd423", "signalId": "github:envoyproxy/envoy:pull_request:46673", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:envoyproxy/envoy:pull_request:46673", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "Order dependent bug", "text": "Commit Message: Fix flaky order-dependent stats_test failures via physical test file separation Additional Description: The tests `NonNumberValueFormatted` and `GaugeNonNumberValueFormatted` both trigger identical error logs emitted via `ENVOY_LOG_PERIODIC_MISC` in `stats.cc`. Because this macro rate-limits logging to prevent log spam, running these tests consecutively in the same target process led to one suppressing the other, causing flaky test failures under randomized execution ordering. Risk Level: low Testing: NA Docs Changes: NA Release Notes: NA Platform Specific Features: NA", "url": "https://github.com/envoyproxy/envoy/pull/46673", "createdAt": "2026-08-12T21:06:33Z", "updatedAt": "2026-08-12T22:54:18Z", "timestamp": "2026-08-12T22:54:18Z", "metrics": { "reactions": 0, "comments": 2 }, "labels": [], "author": "Wenwei-Zhao", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:f5cfc84a74bed01babf6", "signalId": "github:envoyproxy/envoy:pull_request:46674", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:envoyproxy/envoy:pull_request:46674", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "fix: wasm remote code fetch race writing negative cache entry", "text": "● Problem When multiple Envoy worker threads simultaneously call createWasm() for a remote wasm plugin, Thread A starts the HTTP fetch and marks the cache entry in_progress = true. Threads B–N find the entry in_progress, call cb(nullptr) to signal failure, then fall through (missing return) to the code.empty() block. There, they write a negative cache entry (TTL=10s) and start competing fetch attempts. Thread A's successful download is now racing against a poisoned negative cache. For the next 10 seconds, any new call to createWasm() hits RemoteLoadCacheNegativeHit and immediately fails, holding all wasm-filtered requests for up to 10 seconds before fail_open releases them. ``` if (it->second.in_progress) { cb(nullptr); // ← signals FAILURE to the plugin } // ← NO return! falls through code = it->second.code; // empty (Thread 1 still downloading) if (code.empty()) { fetch = true; // ← Thread 2 ALSO starts downloading now it->second.in_progress = true; } ``` ● Fix Add return false immediately after cb(nullptr) in the in_progress branch. Threads B–N still signal failure to the plugin (allowing fail_open to pass the request through), but they no longer fall through to write the negative cache entry or start duplicate fetches. Thread A's download completes uncontested, populates the cache as a successful hit, and all subsequent requests resolve instantly. ● Impact - Eliminates the RemoteLoadCacheNegativeHit cascade that causes 10-second dead zones for wasm-filtered requests - Fixes the CPU spike from competing parallel fetches (all threads racing to download the same binary) - Related: https://github.com/envoyproxy/envoy/issues/25052", "url": "https://github.com/envoyproxy/envoy/pull/46674", "createdAt": "2026-08-12T22:28:46Z", "updatedAt": "2026-08-12T22:29:24Z", "timestamp": "2026-08-12T22:29:24Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [], "author": "eformat", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:18dd947c4fabdb1d6f62", "signalId": "github:envoyproxy/envoy:issue:46531", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:envoyproxy/envoy:issue:46531", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "issue", "title": "GeoIP LookupResult is always const, inhibiting move semantics", "text": "*Description*: In `envoy/geoip/geoip_provider_driver.h`, the type `LookupResult` is defined as an alias to `const absl::flat_hash_map`. The type is usually passed around by rvalue-reference: ``` // from source/extensions/filters/http/geoip/geoip_filter.cc driver_->lookup( Geolocation::LookupRequest{std::move(remote_address)}, [self, &dispatcher = decoder_callbacks_->dispatcher()](Geolocation::LookupResult&& result) { dispatcher.post([self, result]() { if (GeoipFilterSharedPtr filter = self.lock()) { filter->onLookupComplete(std::move(result)); } }); }); ``` Hiding the `const` in the type like this makes the code confusing and makes it impossible to move a `LookupResult`. In the code above for instance, the `result` could be moved into the lambda instead of copied. It can also trigger linters that check for unnecessary uses of `std::move`, for people who have those enabled. I would be willing to refactor this if you're open to it. I think it would not be a big change, just remove the `const` and maybe add some `move`s to take advantage of it. But I thought I'd ask in case this `const` is intended like this.", "url": "https://github.com/envoyproxy/envoy/issues/46531", "createdAt": "2026-08-04T10:15:01Z", "updatedAt": "2026-08-12T21:12:39Z", "timestamp": "2026-08-12T21:12:39Z", "metrics": { "reactions": 0, "comments": 5 }, "labels": [ "enhancement", "area/geoip" ], "author": "syntax-case", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:49e13681e37b6689689c", "signalId": "github:envoyproxy/envoy:pull_request:46672", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:envoyproxy/envoy:pull_request:46672", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "[draft] dym: go sdk for udp listener filter", "text": " Commit Message: Additional Description: Risk Level: Testing: Docs Changes: Release Notes: Platform Specific Features: [Optional Runtime guard:] [Optional Fixes #Issue] [Optional Fixes commit #PR or SHA] [Optional Deprecated:] [Optional [API Considerations](https://github.com/envoyproxy/envoy/blob/main/api/review_checklist.md):]", "url": "https://github.com/envoyproxy/envoy/pull/46672", "createdAt": "2026-08-12T21:04:40Z", "updatedAt": "2026-08-12T21:04:45Z", "timestamp": "2026-08-12T21:04:45Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [], "author": "ovadiagal", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:959d1b02c4a6d55cfc79", "signalId": "github:envoyproxy/envoy:issue:45866", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:envoyproxy/envoy:issue:45866", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "issue", "title": "Guidance on RPM packaging of official release binaries for RHEL/Rocky Linux", "text": "I want to package the official Envoy binary from GitHub releases (e.g., envoy-1.38.3-linux-x86_64) into an RPM for Rocky Linux 9 VM. A few questions: 1. What is the recommended package name when redistributing the official binary as an RPM ? 2. What files should be included for license compliance? Is LICENSE + NOTICE from the repo sufficient? 3. Is there a published GPG public key to verify the signature on checksums.txt.asc? 4. The install docs cover Debian via apt.envoyproxy.io but not RHEL-family. Is self-packaging from GitHub release binaries the recommended approach, or is an RPM repo planned? Relevant Links: - #16867 - #16830 - https://www.envoyproxy.io/docs/envoy/latest/start/install (https://www.envoyproxy.io/docs/envoy/latest/start/install)", "url": "https://github.com/envoyproxy/envoy/issues/45866", "createdAt": "2026-06-28T11:00:39Z", "updatedAt": "2026-08-12T20:11:29Z", "timestamp": "2026-08-12T20:11:29Z", "metrics": { "reactions": 0, "comments": 6 }, "labels": [ "question", "stale", "area/install" ], "author": "SHWETHABHAT1", "state": "closed", "assignees": [], "change": "updated" } }, { "id": "event:f3b63f00c5a33a780b31", "signalId": "github:envoyproxy/envoy:pull_request:46552", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:envoyproxy/envoy:pull_request:46552", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "network_ext_proc: add onNewConnection event handling", "text": "Commit Message: network_ext_proc: add onNewConnection event handling Additional Description: This PR adds first-class support for `onNewConnection` event handling in the NetworkExternalProcessor Key changes: 1. **API Updates**: - `api/envoy/extensions/filters/network/ext_proc/v3/ext_proc.proto`: Added `ConnectionSendMode process_new_connection` (defaulting to `SKIP` for backwards compatibility). - `api/envoy/service/network_ext_proc/v3/network_external_processor.proto`: Added `message NewConnection` containing downstream remote address, downstream local address, requested server name (SNI), and negotiated protocol (ALPN), and added `NewConnection new_connection = 4` to `ProcessingRequest`. 2. **Filter State Machine**: - In `onNewConnection()`: When enabled (`process_new_connection: SEND`), dispatches `ProcessingRequest` with connection attributes and dynamic metadata, starts a timeout timer, and returns `FilterStatus::StopIteration`. - In `onData()` / `onWrite()`: Halts and buffers incoming payload while `onNewConnection` is pending. - In `onReceiveMessage()`: Parses `dynamic_metadata` into `StreamInfo`, handles `connection_status` (CONTINUE, CLOSE, CLOSE_RST), honors `close_stream_to_ext_proc_server` to allow subsequent raw TCP payload to bypass ext_proc, and resumes the filter chain with `read_callbacks_->continueReading()`. - Timeouts & Error Handling: Respects `failure_mode_allow` to either fail-open (`continueReading()`) or close the connection. 3. **Observability**: - Added `new_connection_sent` counter stat. 4. **Documentation & Release Notes**: - Updated network filter docs and added changelog fragment. AI assistance disclosure: This PR was prepared with AI coding assistance. Risk Level: Low (new configuration field defaults to `SKIP`, preserving existing behavior) Testing: Added comprehensive unit tests in `ext_proc_test.cc` and `config_test.cc` covering request contents, dynamic metadata propagation, stream close bypass, connection close/reset, fail-open/fail-close on timeouts and gRPC errors.", "url": "https://github.com/envoyproxy/envoy/pull/46552", "createdAt": "2026-08-05T14:29:43Z", "updatedAt": "2026-08-12T19:58:58Z", "timestamp": "2026-08-12T19:58:58Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [], "author": "botengyao", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:7e24c0256190e23563ec", "signalId": "github:envoyproxy/envoy:pull_request:46460", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:envoyproxy/envoy:pull_request:46460", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "[bp/v1.36] dfp: fix a bug when cluster is removed before async lb be completed (#45064)", "text": "Commit Message: dfp: fix a bug when cluster is removed before async lb be completed Additional Description: In the previous implementation, both the router/DFP cluster may access invalid pointer if a cluster is removed then the request is pending and waiting the async load balancing result. Risk Level: Testing: Docs Changes: Release Notes: Platform Specific Features: [Optional Runtime guard:] [Optional Fixes #Issue] [Optional Fixes commit #PR or SHA] [Optional Deprecated:]", "url": "https://github.com/envoyproxy/envoy/pull/46460", "createdAt": "2026-07-30T13:49:45Z", "updatedAt": "2026-08-12T18:45:55Z", "timestamp": "2026-08-12T18:45:55Z", "metrics": { "reactions": 0, "comments": 4 }, "labels": [], "author": "wbpcode", "state": "closed", "assignees": [ "phlax", "RyanTheOptimist" ], "change": "updated" } }, { "id": "event:dbe74a3027d4af031d61", "signalId": "github:envoyproxy/envoy:pull_request:46461", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:envoyproxy/envoy:pull_request:46461", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "[bp/v1.37] dfp: fix a bug when cluster is removed before async lb be completed (#45064)", "text": "Commit Message: dfp: fix a bug when cluster is removed before async lb be completed Additional Description: In the previous implementation, both the router/DFP cluster may access invalid pointer if a cluster is removed then the request is pending and waiting the async load balancing result. Risk Level: Testing: Docs Changes: Release Notes: Platform Specific Features: [Optional Runtime guard:] [Optional Fixes #Issue] [Optional Fixes commit #PR or SHA] [Optional Deprecated:]", "url": "https://github.com/envoyproxy/envoy/pull/46461", "createdAt": "2026-07-30T13:51:20Z", "updatedAt": "2026-08-12T18:45:37Z", "timestamp": "2026-08-12T18:45:37Z", "metrics": { "reactions": 0, "comments": 3 }, "labels": [], "author": "wbpcode", "state": "closed", "assignees": [ "phlax", "RyanTheOptimist" ], "change": "updated" } }, { "id": "event:18f4a43c1f02e22c17c7", "signalId": "github:envoyproxy/envoy:pull_request:46496", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:envoyproxy/envoy:pull_request:46496", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "http: add support for the QUERY method (RFC 10008)", "text": "## Commit Message Adds support for the `QUERY` request method registered by `RFC 10008`. Before this change, an `HTTP/1` request using the `QUERY` method was rejected by the codec with a `400` and `HPE_INVALID_METHOD`, because the method token is matched against a fixed list of known methods that predates the RFC. `HTTP/2` and `HTTP/3` have no equivalent method allowlist and already forwarded `QUERY`, so the behaviour differed by protocol version. This change adds `QUERY` to that list, so the method is recognized and routed on all three protocol versions. `QUERY` is also added to the `IANA` method registry enforced by the default header validator's `restrict_http_methods` option, so enabling that option no longer rejects a registered method. Recognizing a previously rejected method is user visible, so it is guarded by `envoy.reloadable_features.http1_allow_query_method`, which defaults to true. The guard is latched when the `HTTP/1` parser is constructed, which happens per connection, so flipping it takes effect on new connections without adding a runtime lookup to per-request method validation. Setting it to false restores the previous rejection. Operators could already accept `QUERY` by setting `allow_custom_methods`, but that accepts any token as a method and is marked work-in-progress in the API. ## Additional Description Scoped to Envoy's role as a proxy. Two related areas are deliberately left out: - `QUERY` is not added to `Http::Utility::isSafeRequest()`. Although `RFC 10008` defines `QUERY` as safe and idempotent, that function's callers treat it as \"safe and without content\": it gates whether a request may be sent over `0-RTT` early data, which the default route policy allows for safe requests, and it auto-enables retry on `425`, which for a request with content means buffering that content for the retry. `QUERY` always carries content, so including it changes both behaviours and deserves its own change and guard. A test case pins the current exclusion so the decision is explicit rather than an oversight. - Body-keyed cache keys and the `Accept-Query` response field are origin server concerns rather than proxy ones. The `http_inspector` listener filter is unaffected. Its Balsa path is constructed with `allow_custom_methods` enabled and so never consults the known-method list. Its legacy `http_parser` path rejects every method outside its own list, which is pre-existing behavior already encoded in the `InvalidHttpMethod` test's early return for Balsa. ## Risk Level Low Guarded, and limited to recognizing one additional method token. ## Testing - Unit tests in `balsa_parser_test.cc` covering `QUERY` accepted by default, `QUERY` rejected with the guard disabled, an unrelated method unaffected by the guard, and `QUERY` still accepted via `allow_custom_methods` with the guard off. - Unit test in `codec_impl_test.cc` asserting a `QUERY` request with content-length reaches the decoder with its method, content-type and body intact. - Unit test extension in `base_header_validator_test.cc` for `restrict_http_methods`. - Integration test in `protocol_integration_test.cc` asserting `QUERY` is routed upstream with method and body intact across the full mesh of downstream and upstream protocols, plus a guard-disabled test asserting the `HTTP/1` `400` and that `HTTP/2` and `HTTP/3` are unaffected. ## Docs Changes N/A ## Release Notes ``` changelogs/current/minor_behavior_changes/http__query-method.rst ``` ## Platform Specific Features N/A ## Runtime guard ``` envoy.reloadable_features.http1_allow_query_method ``` defaults to `true`; set to `false` to restore rejecting `QUERY` on `HTTP/1` . Fixes #46404", "url": "https://github.com/envoyproxy/envoy/pull/46496", "createdAt": "2026-08-01T07:07:28Z", "updatedAt": "2026-08-12T18:34:28Z", "timestamp": "2026-08-12T18:34:28Z", "metrics": { "reactions": 0, "comments": 5 }, "labels": [], "author": "guy-with-a-why", "state": "open", "assignees": [ "yanavlasov" ], "change": "updated" } }, { "id": "event:43a042829ef0d8227c5a", "signalId": "github:envoyproxy/envoy:pull_request:46671", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:envoyproxy/envoy:pull_request:46671", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "ExtProc: clarify docs on end_of_stream_without_message field", "text": "Commit Message: ExtProc: clarify docs on end_of_stream_without_message field Additional Description: Clarify description of the field, and mark it as not-implemented-hide to exclude from Envoy docs. Risk Level: Low Testing: N/A Docs Changes: Included in PR Release Notes: N/A Platform Specific Features: N/A CC @yanjunxiang-google", "url": "https://github.com/envoyproxy/envoy/pull/46671", "createdAt": "2026-08-12T18:15:08Z", "updatedAt": "2026-08-12T18:15:20Z", "timestamp": "2026-08-12T18:15:20Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [ "api" ], "author": "markdroth", "state": "open", "assignees": [ "wbpcode" ], "change": "updated" } }, { "id": "event:c6279b22e3b0e691d4fa", "signalId": "github:envoyproxy/envoy:issue:6614", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:envoyproxy/envoy:issue:6614", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "issue", "title": "Open Request Cost Aggregation (ORCA)", "text": "Today in Envoy, simple load balancing decisions can be made by taking into account local or global knowledge of a backend’s load, for example CPU. More sophisticated load balancing decisions are possible with application specific knowledge, e.g. queue depth, or by combining multiple metrics. This is useful for services that may be resource constrained along multiple dimensions (e.g. both CPU and memory may become bottlenecks, depending on the applied load and execution environment, it’s not possible to tell which upfront) and where these dimensions do not slot within predefined categories (e.g. the resource may be “number of free threads in a pool”, disk IOPS, etc.). https://docs.google.com/document/d/1NSnK3346BkBo1JUU3I9I5NYYnaJZQPt8_Z_XCBCI3uA/edit# provides a design proposal for an Open Request Cost Aggregation (ORCA) standard for conveying this information between proxies like Envoy and upstreams. We propose that this become a standard part of UDPA and supported by Envoy. The design document is in draft stage; from offline discussions I think the need for something like this is not very controversial, we can iterate on aspects of the design here.", "url": "https://github.com/envoyproxy/envoy/issues/6614", "createdAt": "2019-04-17T03:19:28Z", "updatedAt": "2026-08-12T18:03:46Z", "timestamp": "2026-08-12T18:03:46Z", "metrics": { "reactions": 13, "comments": 47 }, "labels": [ "enhancement", "help wanted" ], "author": "htuch", "state": "open", "assignees": [ "Mythra" ], "change": "updated" } }, { "id": "event:4c2a10b5c4e6d521149b", "signalId": "github:envoyproxy/envoy:pull_request:46603", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:envoyproxy/envoy:pull_request:46603", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "ai_protocol_manager: add response handling and extract response token usage oai, ahth, gemini", "text": "Adds response-side (encode-path) handling to the AI Protocol Manager filter: 2xx SSE and JSON responses in the OpenAI (Chat Completions + Responses API), Anthropic (Messages), and Gemini (`generateContent`/`streamGenerateContent`) dialects are observed as they stream through, and normalized token usage is published as dynamic metadata at a clean end of stream. Observe-only: the filter never stops iteration or mutates the response, and extraction failures cannot affect the stream. - one namespace (default `envoy.ai.token_usage`) in both metadata forms — a typed `envoy.data.ai.v3.TokenUsage` record (authoritative, full `uint64` precision) and an untyped Struct projection of it for `%DYNAMIC_METADATA%`/CEL. ext_proc consumers receive it via `metadata_options.forwarding_namespaces`. - `input_tokens`/`output_tokens` are inclusive in every dialect (cache, tool-use, and reasoning buckets are subset breakdowns), and `total_tokens` is their sum; a disagreeing provider total is kept as `reported_total_tokens`. Counts accumulate natively per event and are canonicalized once at end of stream. `extraction_status` (`complete`/`partial`) reports extraction quality. - dialect auto-detected from response shape, or pinned via `api_format` (a wire format, not a provider identity). The extractor config is a `oneof` for future custom extractors. - SSE state hard-capped by `max_event_size` (1MiB default), JSON by `max_inspected_body_size`, per-stream parse work by `max_parsed_events`; in-frame events are zero-copy, non-usage events are skipped before parsing, and buffers charge the stream's memory account. - dual filter with identical extraction in either chain; first publication owns the namespace. `request_handling.payload_offload_enabled: false` enables a response-only installation (pure request passthrough), e.g. for observation on a DFP egress cluster. For API shepherds: (1) placement of the emitted message under `envoy.data.ai.v3` (WIP-annotated); (2) the future `custom_extractor` oneof member. Deferred with rationale: selective streaming (SAX) extractor, common SSE decoder shared with `sse_to_metadata`, per-route `api_format` pinning, usage-on-abort publication. **Testing:** - E2E (live providers, DFP + auto-detect) — access-log records from a real run: | Provider | Framing | Extracted (in/out/total) | Notes | |---|---|---|---| | OpenAI `gpt-4o-mini` | JSON + SSE | 13 / 7 / 20 | terminal `include_usage` chunk | | Anthropic `claude-haiku-4-5` | JSON + SSE | 13 / 10 / 23 | total computed (absent on wire) | | Gemini `gemini-3.6-flash` | JSON | 6 / 661 / 667 | 654 reasoning tokens summed into output | | Gemini `gemini-3.6-flash` | SSE | 6 / 760 / 766 | cumulative snapshots, last wins | All six requests: `extraction_status: complete`, auto-detected `api_format`, zero parse-error/partial/budget counters. Also validated live: OpenAI Responses API, OpenAI prompt caching (`cached_input_tokens: 2816`), and Anthropic cache write/read (wire `input_tokens: 9` + `cache_read: 6761` → canonical `input_tokens: 6770`). https://github.com/botengyao/envoy/pull/1736/changes Commit Message: add response handling and extract response token usage oai, ahth, gemini Additional Description: Risk Level: Low — opt-in behavior in an alpha (work-in-progress) filter; observe-only and fail-open by construction. Testing: all unit, integration, fuzz, and benchmark tests are added. Docs Changes: yes", "url": "https://github.com/envoyproxy/envoy/pull/46603", "createdAt": "2026-08-09T21:54:17Z", "updatedAt": "2026-08-12T17:42:07Z", "timestamp": "2026-08-12T17:42:07Z", "metrics": { "reactions": 0, "comments": 2 }, "labels": [ "api" ], "author": "botengyao", "state": "open", "assignees": [ "penguingao", "wbpcode" ], "change": "updated" } }, { "id": "event:9d9e0e000229efd5bac2", "signalId": "github:envoyproxy/envoy:pull_request:46479", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:envoyproxy/envoy:pull_request:46479", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "tls: allow multiple TLS certificates in the upstream when using a custom TLS certificate selector", "text": "Commit Message: Allow multiple TLS certificates in the upstream tls context when using a custom TLS certificate selector. The single cert check is kept if one is not defined. Additional Description: We are working on an internal TLS certificate selector for UpstreamTLSContext that can select between multiple client certificate. By default only one is allowed, so we need a way to allow multiple once our custom TLS certificate selector is enabled. Risk Level: Medium Testing: Added unit tests, tested manually to check it works with our custom cert selector. Docs Changes: Added documentation in the API proto for `tls_certificates` to indicate multiple certs are allowed in a client context when a custom TLS certificate selector is used. Release Notes: Added a release note under new features. Platform Specific Features: N/A", "url": "https://github.com/envoyproxy/envoy/pull/46479", "createdAt": "2026-07-31T05:45:00Z", "updatedAt": "2026-08-12T17:33:01Z", "timestamp": "2026-08-12T17:33:01Z", "metrics": { "reactions": 0, "comments": 6 }, "labels": [], "author": "Berro321", "state": "open", "assignees": [ "adisuissa", "botengyao" ], "change": "updated" } }, { "id": "event:d4da3ed50b17809350ed", "signalId": "github:envoyproxy/envoy:pull_request:46300", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:envoyproxy/envoy:pull_request:46300", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "AI Protocol Parser: add ParserConfig for the wuffs JSON parser", "text": "Introduces ParserConfig to bound the parsing and capture and control streaming JSON field extraction on top of WuffsJsonCursor. The use of ParserConfig are shown in the test handler, agentic(MCP/A2A) and LLM(openAI/Gemini) handler will be implemented in the next PRs. Capture limitation, (TODO define good defaults) - max_body_bytes: pre-feed cap on raw bytes entering the cursor. - max_per_scalar_bytes: per-string-value cap. Over-budget values are rejected — dropped entirely - max_total_scalar_capture_bytes: body-wide retention budget across all captured values. A value that would overflow the total is dropped without consuming budget, so later smaller values still fit. - max_element_capture_bytes: per container byte-range capture. Two capture modes 1. Spec-based extraction (`extract_fields`) — the caller declares which fields to extract as pattern paths (\"model\", \"params._meta.traceparent\", \"messages[].role\", \"tools[].function.name\"). 2. Capture-all mode (`capture_all_scalars`) — captures every scalar value (strings, numbers, booleans, nulls) at every depth to maxDepth Clean-up and Clarification - clean up and polish the code comment - buildIndex/PatternPath and path tracking are not needed anymore, replaced by matchesPatternPath - number token is also bounded by max_body_bytes introduced in this PR. https://github.com/envoyproxy/envoy/issues/44681", "url": "https://github.com/envoyproxy/envoy/pull/46300", "createdAt": "2026-07-22T02:26:22Z", "updatedAt": "2026-08-12T16:41:27Z", "timestamp": "2026-08-12T16:41:27Z", "metrics": { "reactions": 0, "comments": 3 }, "labels": [], "author": "tyxia", "state": "open", "assignees": [ "penguingao", "yanavlasov", "agrawroh" ], "change": "updated" } }, { "id": "event:e1969e61413e104c2811", "signalId": "github:envoyproxy/envoy:pull_request:46669", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:envoyproxy/envoy:pull_request:46669", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "orca: make OOB active_sessions gauge composable across managers", "text": " Commit Message: Additional Description: Risk Level: Testing: Docs Changes: Release Notes: Platform Specific Features: [Optional Runtime guard:] [Optional Fixes #Issue] [Optional Fixes commit #PR or SHA] [Optional Deprecated:] [Optional [API Considerations](https://github.com/envoyproxy/envoy/blob/main/api/review_checklist.md):]", "url": "https://github.com/envoyproxy/envoy/pull/46669", "createdAt": "2026-08-12T16:23:40Z", "updatedAt": "2026-08-12T16:37:14Z", "timestamp": "2026-08-12T16:37:14Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [], "author": "jukie", "state": "closed", "assignees": [], "change": "updated" } }, { "id": "event:2b75c5fca683b0ad7175", "signalId": "github:envoyproxy/envoy:pull_request:45983", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:envoyproxy/envoy:pull_request:45983", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "stats: migrate almost all HTTP to new API", "text": "Commit Message: stats: migrate almost all HTTP to new API Additional Description: Parts of https://github.com/envoyproxy/envoy/issues/20289. This migrate the previous stats creation to use new tags-friendly API. But note, before we merge https://github.com/envoyproxy/envoy/pull/45846 and enable it explicitly. This won't bring any changes to the final behavior because the legacy mode will ignore the provided tags but only use the flat name. Risk Level: mid. Changed too much code. Orz. Testing: unit. Docs Changes: n/a. Release Notes: n/a. Platform Specific Features: n/a.", "url": "https://github.com/envoyproxy/envoy/pull/45983", "createdAt": "2026-07-05T13:02:46Z", "updatedAt": "2026-08-12T16:17:39Z", "timestamp": "2026-08-12T16:17:39Z", "metrics": { "reactions": 0, "comments": 4 }, "labels": [ "stale" ], "author": "wbpcode", "state": "closed", "assignees": [ "yanavlasov" ], "change": "updated" } }, { "id": "event:44bccbe4dea40a135d7e", "signalId": "github:envoyproxy/envoy:pull_request:45914", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:envoyproxy/envoy:pull_request:45914", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "stats: migrate rds/scope rds to use new stats API", "text": "Commit Message: stats: migrate rds/scope rds to use new stats API Additional Description: Parts of #20289. This migrate the previous stats creation to use new tags-friendly API. But note, before we merge https://github.com/envoyproxy/envoy/pull/45846 and enable it explicitly. This won't bring any changes to the final behavior because the legacy mode will ignore the provided tags but only use the flat name. Risk Level: low. Testing: unit. Docs Changes: n/a. Release Notes: n/a. Platform Specific Features: n/a.", "url": "https://github.com/envoyproxy/envoy/pull/45914", "createdAt": "2026-07-01T13:31:13Z", "updatedAt": "2026-08-12T16:17:37Z", "timestamp": "2026-08-12T16:17:37Z", "metrics": { "reactions": 0, "comments": 4 }, "labels": [ "stale" ], "author": "wbpcode", "state": "open", "assignees": [ "ggreenway", "paul-r-gall" ], "change": "updated" } }, { "id": "event:b7716e9a31e6cd03f4be", "signalId": "github:envoyproxy/envoy:issue:46665", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:envoyproxy/envoy:issue:46665", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "issue", "title": "cluster upstream_rq_timeout increments on requests that also complete successfully (rq_success == rq_total, rq_timeout independently non-zero)", "text": "### Summary For one specific upstream cluster, `envoy_cluster_upstream_rq_timeout` (and the equivalent `/clusters?format=json` admin stat `rq_timeout`) increments on requests that also complete successfully. On the same host, in the same admin snapshot, `rq_success` equals `rq_total` exactly, while `rq_timeout` is simultaneously non-zero — i.e. Envoy is counting some fraction of requests as *both* fully successful and timed out. This is not a rare edge case: on the affected cluster the ratio is currently 68-72% (`rq_timeout`/`rq_total`) and has persisted across proxy restarts, a route timeout config change, and an Envoy patch version bump, with the underlying application-level failure rate provably at zero throughout. ### Environment - Envoy `v1.35.10` (also reproduced on `v1.35.9`), via Contour `1.33.3` (`projectcontour/contour` chart) - Downstream: Gateway API `HTTPRoute`, no retry/hedge policy configured - Upstream: a single Kubernetes Service, 2 endpoints, plain HTTP/1.1 (no TLS), `StreamableHTTP`/JSON-over-HTTP traffic (not gRPC) - Traffic pattern: bursty/low-volume (roughly 1 request every few seconds), long-lived-ish client sessions, some requests carry `Connection: keep-alive` ### Evidence `GET /clusters?format=json` on the Contour-managed Envoy, same cluster, two hosts, one snapshot: ``` host .229: cx_connect_fail: (absent/0) cx_total: 226 rq_success: 290 rq_timeout: 199 rq_total: 290 host .87: cx_connect_fail: (absent/0) cx_total: 229 rq_success: 289 rq_timeout: 207 rq_total: 289 ``` `rq_success == rq_total` on both hosts. `rq_timeout` is not subtracted from either — it is tracked as an independent, non-exclusive counter. Cross-checked against the equivalent Prometheus stats (`envoy_cluster_upstream_rq_completed`, `envoy_cluster_upstream_rq_timeout`, `envoy_cluster_upstream_rq{envoy_response_code=...}`) over the same window: - `envoy_cluster_upstream_rq_completed` == `sum(envoy_cluster_upstream_rq)` by response code, exactly, at every sampled timestamp — every completed request has a normal, successful response code (`200`, mostly). No unaccounted/uncoded completions. - `envoy_cluster_upstream_cx_connect_fail`, `..._cx_connect_timeout`, `..._cx_pool_overflow`, `..._cx_idle_timeout`, `..._rq_per_try_timeout`, `..._rq_max_duration_reached`, `..._rq_rx_reset`, `..._rq_tx_reset` are all zero for this cluster throughout the observation window. - `envoy_cluster_health_check_*` does not exist for this cluster at all — no active health check is configured. - `histogram_quantile` on `envoy_cluster_upstream_rq_time_bucket` shows p50/p90/p99 well under any configured timeout (single-digit-to-low-double-digit milliseconds at the median; a small tail up to a few seconds). - No retry or hedge policy is configured on the route (confirmed via the live `config_dump`), so `rq_timeout` cannot be a per-try-timeout artifact of a retry we don't have. - The route in question does have an explicit `timeouts.request: 60s` (via Gateway API `HTTPRoute.spec.rules[].timeouts.request`, Contour v1.28.0+) — adding this reduced the *rate* of the effect by roughly 2-3x but did not eliminate it, and did not change the qualitative pattern (still `rq_success == rq_total` with `rq_timeout` ticking independently). ### What I've ruled out - Retries/hedging inflating `rq_timeout` via per-try semantics — none configured. - Connection pool exhaustion / stale pooled connections — all `cx_*` failure counters are zero. - A downstream idle/stream-idle timeout mismatch — `cx_idle_timeout` is zero, and Contour's `stream-idle-timeout` default (5m) is far looser than the actual p99 latency (low seconds). - Health-check-related eviction/probing — no health check exists on this cluster. - Actual application-level failures — response-code accounting balances exactly with zero 5xx growth throughout multi-hour windows, including windows where the timeout ratio itself was 60-90%. ### What I have NOT been able to determine The exact internal code path that increments `rq_timeout` without the request otherwise appearing to fail. My working hypothesis, unconfirmed, is a race in the router filter between the per-request timer callback and the upstream response-decode callback — i.e. the timer fires (and increments the stat) at approximately the same instant the real response is already committed and gets forwarded downstream anyway — but I have not been able to prove this without Envoy-internal tracing/debug logging beyond what `/stats` and `/clusters` expose. ### Reproduction I don't yet have a minimal standalone repro (e.g. a bare Envoy config + toy upstream) — this is observed on a real Contour-managed deployment with the traffic characteristics described above (low/bursty request volume, plain HTTP/1.1, JSON-RPC-over-HTTP style requests with `Connection: keep-alive`, no retries configured, an explicit but generous `route.timeout`). If a maintainer can suggest what to instrument or which debug log level would isolate the code path (e.g. `router` or `connection` debug components), I'm happy to reproduce with that logging enabled and report back. ### Ask - Does anything in the router filter legitimately increment `rq_timeout` for a request that ultimately succeeds (e.g. a timer/response race, or a stat that's intentionally non-exclusive with `rq_success`)? If this is expected/documented behavior I've missed, a pointer would be appreciated. - If not, any guidance on what to capture (debug log component/level, `/stats` more targeted) to pin the exact code path down further would let me turn this into a proper minimal repro.", "url": "https://github.com/envoyproxy/envoy/issues/46665", "createdAt": "2026-08-12T15:25:59Z", "updatedAt": "2026-08-12T15:33:19Z", "timestamp": "2026-08-12T15:33:19Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [], "author": "aleemshah-insignis", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:0c9e6b3bfdb88bc3fd65", "signalId": "github:envoyproxy/envoy:issue:46666", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:envoyproxy/envoy:issue:46666", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "issue", "title": "health check probes blocked indefinitely when EDS initialFetchTimeout is 0s", "text": "*Title*: *health check probes blocked indefinitely when EDS initialFetchTimeout is 0s* *Description*: After I set EDS initialFetchTimeout as 0s, all envoy gateway conformance and e2e test cases failed in waiting for health check activity to appear. *Repro steps*: 1. set initialFetchTimeout: 0s 2. rerun all envoy gateway e2e test cases *Logs*: > === RUN TestE2E/BackendHealthCheckActiveHTTP/active_http > helpers.go:821: 2026-08-11T12:51:31.009924331Z: Conditions matched expectations > helpers.go:821: 2026-08-11T12:51:31.009977872Z: Route gateway-conformance-infra/http-with-health-check-active-http-pass Parents matched expectations > … > backend_health_check.go:112: 2026-08-11T12:52:40.144747982Z: cluster fail health check: new failure count: 2 (total: 2) > http.go:306: 2026-08-11T12:52:41.046201267Z: timeout while waiting after 60 attempts, 0/3 successes > > === RUN TestGatewayAPIConformance/BackendTLSPolicyConflictResolution/BackendTLSPolicies_targeting_the_same_Service_with_and_without_a_section_name/HTTP_request_sent_to_Service_using_the_BackendTLSPolicy_with_section_name_should_succeed > backendtlspolicy-conflict-resolution.go:130: 2026-08-11T12:52:47.817510589Z: Making GET request to host abc.example.com via http://172.18.0.200/backendtlspolicy-not-conflicted-with-section-name > http.go:325: 2026-08-11T12:52:47.828189571Z: Response expectation failed for request: {URL: {Scheme:http Opaque: User: Host:172.18.0.200 Path:/backendtlspolicy-not-conflicted-with-section-name Fragment: RawQuery: RawPath: RawFragment: ForceQuery:false OmitHost:false}, Host: abc.example.com, Protocol: HTTP, Method: GET, Headers: map[X-Echo-Set-Header:[]], UnfollowRedirect: false, ServerName: , ServerCertificate: , ClientCertificate: , ClientCertificateKey: } not ready yet: expected status code to be one of [200], got 400. CRes: &{400 -1 HTTP/1.1 map[Date:[Tue, 11 Aug 2026 12:52:47 GMT]] []} (after 1.732µs) >", "url": "https://github.com/envoyproxy/envoy/issues/46666", "createdAt": "2026-08-12T15:30:55Z", "updatedAt": "2026-08-12T15:30:55Z", "timestamp": "2026-08-12T15:30:55Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [ "bug", "triage" ], "author": "yuehaii", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:3ff687b8a4c6012476f5", "signalId": "github:envoyproxy/envoy:pull_request:46601", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:envoyproxy/envoy:pull_request:46601", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "Disable fmtlib Unicode support on Windows", "text": "The FMT_UNICODE is a Windows MSVC specific option. It has not effect on Linux build. Risk Level: none Testing: unit tests Docs Changes: no Release Notes: no Platform Specific Features: Windows specific", "url": "https://github.com/envoyproxy/envoy/pull/46601", "createdAt": "2026-08-09T17:39:36Z", "updatedAt": "2026-08-12T15:04:19Z", "timestamp": "2026-08-12T15:04:19Z", "metrics": { "reactions": 0, "comments": 3 }, "labels": [], "author": "yanavlasov", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:6b4217484e44e092c6ea", "signalId": "github:envoyproxy/envoy:pull_request:46613", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:envoyproxy/envoy:pull_request:46613", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "network: send zero-length UDP datagrams", "text": "Preserve empty datagrams across all UDP send paths. Justification: RFC 768 permits UDP datagrams with an empty payload: the minimum UDP Length is 8 octets, corresponding to the UDP header alone. Envoy currently treats these valid datagrams as no-op writes and silently drops them. This change ensures they reach the socket send operation for connected and unconnected UDP sockets. Commit Message: Additional Description: Risk Level: Testing: Done Docs Changes: Release Notes: Platform Specific Features:", "url": "https://github.com/envoyproxy/envoy/pull/46613", "createdAt": "2026-08-10T13:37:06Z", "updatedAt": "2026-08-12T14:38:16Z", "timestamp": "2026-08-12T14:38:16Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [], "author": "nezdolik", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:f1ab4836672c2506262b", "signalId": "github:envoyproxy/envoy:pull_request:46645", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:envoyproxy/envoy:pull_request:46645", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "APM: add utilities to define and validate JSON schema. add the first schema - OpenAI chat completion schema", "text": "Commit Message: add utilities to define and validate JSON schema. add the first schema - OpenAI chat completion schema This allows us to structurally define a JSON payload schema for AI requests. It is useful for validation, and later transcoding. This is part of #44681. I used AI to generate this PR. I have read and fully understand this PR. Additional Description: https://github.com/penguingao/thoughts/blob/main/20260727_AI_FILTER.md Risk Level: Medium Testing: unit tests Docs Changes: updated the extension docs, but this is still an alpha filter under development Release Notes: N/A - WIP alpha filter Platform Specific Features: no", "url": "https://github.com/envoyproxy/envoy/pull/46645", "createdAt": "2026-08-11T16:25:52Z", "updatedAt": "2026-08-12T14:22:25Z", "timestamp": "2026-08-12T14:22:25Z", "metrics": { "reactions": 0, "comments": 4 }, "labels": [], "author": "penguingao", "state": "open", "assignees": [ "wbpcode", "botengyao", "tyxia" ], "change": "updated" } }, { "id": "event:655a320d954bcd32f69d", "signalId": "github:envoyproxy/envoy:pull_request:43355", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:envoyproxy/envoy:pull_request:43355", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "Queue policy extension", "text": "As agreed in https://github.com/envoyproxy/envoy/pull/28982 we first introduce extension point for queue policy to support more algorithms in future (e.g. codel, adaptive lifo). This PR introduces fifo queue extension currently used in core code. Commit Message: Additional Description: Risk Level: Testing: Docs Changes: Release Notes: Platform Specific Features: [Optional Runtime guard:] [Optional Fixes #Issue] [Optional Fixes commit #PR or SHA] [Optional [API Considerations](https://github.com/envoyproxy/envoy/blob/main/api/review_checklist.md):]", "url": "https://github.com/envoyproxy/envoy/pull/43355", "createdAt": "2026-02-06T14:35:45Z", "updatedAt": "2026-08-12T14:18:42Z", "timestamp": "2026-08-12T14:18:42Z", "metrics": { "reactions": 0, "comments": 19 }, "labels": [], "author": "nezdolik", "state": "open", "assignees": [ "tonya11en", "yanavlasov", "markdroth", "balrawi-figma" ], "change": "updated" } }, { "id": "event:65627eb9ff5cd78d4688", "signalId": "github:envoyproxy/envoy:pull_request:46650", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:envoyproxy/envoy:pull_request:46650", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "repo: remove zuercher from code ownership/maintainer", "text": "Risk Level: low Testing: n/a Docs Changes: n/a Release Notes: n/a Platform Specific Features: n/a", "url": "https://github.com/envoyproxy/envoy/pull/46650", "createdAt": "2026-08-11T19:02:06Z", "updatedAt": "2026-08-12T14:10:14Z", "timestamp": "2026-08-12T14:10:14Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "zuercher", "state": "closed", "assignees": [], "change": "updated" } }, { "id": "event:6b859f9c4fdc26611047", "signalId": "github:envoyproxy/envoy:pull_request:46684", "event": "discovered", "observedAt": "2026-08-13T16:19:22.035158Z", "changedFields": [], "signal": { "id": "github:envoyproxy/envoy:pull_request:46684", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "coroutine: add ASSIGN_OR_CO_RETURN and CO_RETURN_IF_ERROR macros", "text": "Commit Message: These are the macros that mirror directly `RETURN_IF_ERROR` and `ASSIGN_OR_RETURN` but for `Envoy::Coroutine::Task` and `Envoy::Coroutine::Task>` coroutines. Additional Description: Risk Level: low Testing: unit test Docs Changes: N/A Release Notes: no - internal helper utilities Platform Specific Features: N/A", "url": "https://github.com/envoyproxy/envoy/pull/46684", "createdAt": "2026-08-13T14:19:38Z", "updatedAt": "2026-08-13T16:00:32Z", "timestamp": "2026-08-13T16:00:32Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [], "author": "penguingao", "state": "closed", "assignees": [], "change": "new" } }, { "id": "event:0565b5f6151cbeda5f61", "signalId": "github:envoyproxy/envoy:pull_request:46621", "event": "discovered", "observedAt": "2026-08-13T16:19:22.035158Z", "changedFields": [], "signal": { "id": "github:envoyproxy/envoy:pull_request:46621", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "quic: promote HTTP/3 API status from alpha to stable", "text": "QUIC/HTTP3 is well-supported both internally and externally in Envoy. CVEs in it are treated with the highest priority. It's long-overdue to take it out of alpha. Changes: - Remove 'QUIC upstream support is currently not ready for internet use' warnings from http_protocol_options.proto (ExplicitHttpConfig, UseDownstreamHttpConfig, AutoHttpConfig). - Remove stale '(soon)' qualifier from AutoHttpConfig comment. - Remove 'QUIC implementation is not production ready yet' comment from the HTTP3 CodecClientType enum in http.proto. - Remove the alpha/not-production-ready warning from the HTTP/3 arch overview documentation. - Promote all QUIC extensions from alpha to stable in extensions_metadata.yaml: - envoy.quic.proof_source.filter_chain - envoy.quic.server_preferred_address.fixed - envoy.quic.server_preferred_address.datasource - envoy.quic.deterministic_connection_id_generator - envoy.quic.connection_id_generator.quic_lb - envoy.quic.crypto_stream.server.quiche - envoy.quic.connection_debug_visitor.basic - envoy.quic.connection_debug_visitor.quic_stats Risk Level: Low (documentation and metadata only) Testing: N/A (no code changes) Created with AI", "url": "https://github.com/envoyproxy/envoy/pull/46621", "createdAt": "2026-08-10T22:48:31Z", "updatedAt": "2026-08-13T15:59:15Z", "timestamp": "2026-08-13T15:59:15Z", "metrics": { "reactions": 0, "comments": 3 }, "labels": [], "author": "abeyad", "state": "closed", "assignees": [ "adisuissa", "RyanTheOptimist" ], "change": "new" } }, { "id": "event:61cf38366a3c3d705ea5", "signalId": "github:envoyproxy/envoy:pull_request:46601", "event": "changed", "observedAt": "2026-08-13T16:19:22.035158Z", "changedFields": [ "updatedAt", "metrics", "labels" ], "signal": { "id": "github:envoyproxy/envoy:pull_request:46601", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "Disable fmtlib Unicode support on Windows", "text": "The FMT_UNICODE is a Windows MSVC specific option. It has not effect on Linux build. Risk Level: none Testing: unit tests Docs Changes: no Release Notes: no Platform Specific Features: Windows specific", "url": "https://github.com/envoyproxy/envoy/pull/46601", "createdAt": "2026-08-09T17:39:36Z", "updatedAt": "2026-08-13T15:49:00Z", "timestamp": "2026-08-13T15:49:00Z", "metrics": { "reactions": 0, "comments": 5 }, "labels": [ "no stalebot" ], "author": "yanavlasov", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:1c9fa945bc41d15dda5c", "signalId": "github:envoyproxy/envoy:pull_request:46318", "event": "discovered", "observedAt": "2026-08-13T16:19:22.035158Z", "changedFields": [], "signal": { "id": "github:envoyproxy/envoy:pull_request:46318", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "ext_proc: adding direct mode_override support", "text": "This is a follow up implementation for https://github.com/envoyproxy/envoy/pull/46315", "url": "https://github.com/envoyproxy/envoy/pull/46318", "createdAt": "2026-07-22T21:30:10Z", "updatedAt": "2026-08-13T15:45:55Z", "timestamp": "2026-08-13T15:45:55Z", "metrics": { "reactions": 0, "comments": 10 }, "labels": [ "api" ], "author": "yanjunxiang-google", "state": "open", "assignees": [ "stevenzzzz", "adisuissa", "yanavlasov", "rshriram", "tyxia" ], "change": "new" } }, { "id": "event:ef804325a5ea8179cf71", "signalId": "github:envoyproxy/envoy:pull_request:46676", "event": "changed", "observedAt": "2026-08-13T16:19:22.035158Z", "changedFields": [ "text", "updatedAt" ], "signal": { "id": "github:envoyproxy/envoy:pull_request:46676", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "Allow connection teardown even when cert selection is not yet complete", "text": "https://github.com/envoyproxy/envoy/pull/45755 allowed the socket state to transition to `ShutdownSent` before cert selection is complete (as intended). However, this could cause `ENVOY_BUG` to be thrown when `SslSocket::onAsynchronousCertificateSelectionComplete()` is invoked. This patch updates `SslSocket::onAsynchronousCertificateSelectionComplete` to allow this socket state which is consistent with the implementation of `SslSocket::onAsynchronousCertValidationComplete` and avoids the `ENVOY_BUG` in the case of valid states such as `ShutdownSent`. Change-Id: I155b874accd54affa65bfa0b744ff99154060570 Commit Message: Additional Description: Risk Level: Testing: Docs Changes: Release Notes: Platform Specific Features: [Optional Runtime guard:] [Optional Fixes #Issue] [Optional Fixes commit #PR or SHA] [Optional Deprecated:] [Optional [API Considerations](https://github.com/envoyproxy/envoy/blob/main/api/review_checklist.md):]", "url": "https://github.com/envoyproxy/envoy/pull/46676", "createdAt": "2026-08-13T01:58:15Z", "updatedAt": "2026-08-13T15:40:27Z", "timestamp": "2026-08-13T15:40:27Z", "metrics": { "reactions": 0, "comments": 2 }, "labels": [], "author": "etruong42", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:27214612422af7cb28d1", "signalId": "github:envoyproxy/envoy:pull_request:46683", "event": "changed", "observedAt": "2026-08-13T16:19:22.035158Z", "changedFields": [ "title", "text", "updatedAt" ], "signal": { "id": "github:envoyproxy/envoy:pull_request:46683", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "Ensure upstream hosts have rebalanced utilization", "text": "... before asserting new traffic patterns in test Commit Message: Additional Description: Risk Level: Testing: Docs Changes: Release Notes: Platform Specific Features: [Optional Runtime guard:] [Optional Fixes #Issue] [Optional Fixes commit #PR or SHA] [Optional Deprecated:] [Optional [API Considerations](https://github.com/envoyproxy/envoy/blob/main/api/review_checklist.md):]", "url": "https://github.com/envoyproxy/envoy/pull/46683", "createdAt": "2026-08-13T13:14:57Z", "updatedAt": "2026-08-13T15:38:58Z", "timestamp": "2026-08-13T15:38:58Z", "metrics": { "reactions": 0, "comments": 2 }, "labels": [], "author": "etruong42", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:823ebce12c31386b5fec", "signalId": "github:envoyproxy/envoy:pull_request:46502", "event": "changed", "observedAt": "2026-08-13T16:19:22.035158Z", "changedFields": [ "updatedAt" ], "signal": { "id": "github:envoyproxy/envoy:pull_request:46502", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "Support hot restart handoff for connectionless UDP flows", "text": "Commit Message: udp: Support hot restart handoff for connectionless UDP flows Additional Description: The parent instance keeps serving established UDP flows while draining and forwards packets of unknown flows to the child over the hot restart RPC, instead of going dark between drain start and parent shutdown. Risk Level: Medium Testing: Added unit and integration tests, manual Docs Changes: - Added `envoy.resource_limits.listener..udp_flow_limit`. - Added `downstream_flows_active, Gauge`, if equal to the limit, flows might get misrouted during hotrestart Release Notes: Added new_features entry Platform Specific Features: N/A Fixes #34732", "url": "https://github.com/envoyproxy/envoy/pull/46502", "createdAt": "2026-08-01T12:28:12Z", "updatedAt": "2026-08-13T15:36:59Z", "timestamp": "2026-08-13T15:36:59Z", "metrics": { "reactions": 0, "comments": 7 }, "labels": [ "api" ], "author": "filipcacky", "state": "open", "assignees": [ "nezdolik", "markdroth" ], "change": "updated" } }, { "id": "event:f4d12256acf7c5ae7b8b", "signalId": "github:envoyproxy/envoy:pull_request:46622", "event": "discovered", "observedAt": "2026-08-13T16:19:22.035158Z", "changedFields": [], "signal": { "id": "github:envoyproxy/envoy:pull_request:46622", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "c-ares: disable shared resolver by default", "text": "Commit Message: c-ares: disable shared resolver by default Additional Description: DnsFilter would call createDnsResolver() from a workerthread that would cause a race when sharing dns resolvers. Turn off this feature until the race is fixed. Relates to https://github.com/envoyproxy/envoy/pull/46577 and https://github.com/envoyproxy/envoy/pull/45073 Risk Level: low Testing: Docs Changes: Release Notes: Platform Specific Features:", "url": "https://github.com/envoyproxy/envoy/pull/46622", "createdAt": "2026-08-10T23:28:22Z", "updatedAt": "2026-08-13T15:35:31Z", "timestamp": "2026-08-13T15:35:31Z", "metrics": { "reactions": 0, "comments": 6 }, "labels": [], "author": "andy-fong", "state": "closed", "assignees": [], "change": "new" } }, { "id": "event:0e26f6ffb13cd815dbea", "signalId": "github:envoyproxy/envoy:pull_request:46668", "event": "changed", "observedAt": "2026-08-13T16:19:22.035158Z", "changedFields": [ "updatedAt" ], "signal": { "id": "github:envoyproxy/envoy:pull_request:46668", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "Rescope Logger::Levels enum so it can be moved to envoy/ directory", "text": "The main change is in the source/common/common/base_logger.h, moving the Levels enum out of the Logger class into the outer Logger namespace. This is intermediate step to using this enum in Envoy's interfaces in the envoy/ directory. This will prevent leaking of the spdlog dependency to proprietary components that need to manipulate Envoy's log level programmatically. Risk Level: low Testing: unit tests Docs Changes: no Release Notes: no Platform Specific Features: no", "url": "https://github.com/envoyproxy/envoy/pull/46668", "createdAt": "2026-08-12T15:37:40Z", "updatedAt": "2026-08-13T15:35:25Z", "timestamp": "2026-08-13T15:35:25Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [], "author": "yanavlasov", "state": "closed", "assignees": [], "change": "updated" } }, { "id": "event:79600f902a3e75dc7c92", "signalId": "github:envoyproxy/envoy:pull_request:45674", "event": "changed", "observedAt": "2026-08-13T16:19:22.035158Z", "changedFields": [ "updatedAt" ], "signal": { "id": "github:envoyproxy/envoy:pull_request:45674", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "hot restart: propagate programmatic stat tags across restart", "text": "**Commit Message:** hot restart: propagate programmatic stat tags across restart **Additional Description:** Stats created with programmatic tags (via `Scope::*FromStatNameWithTags` / the tag-aware `*FromTaggedName` API) embed their tag *values* into the flat stat name while keeping a clean `tagExtractedName` and a set of tags. This works on a fresh process, but breaks across a hot restart: - The parent serializes each counter/gauge to the child as **name string → value** only (`HotRestartingParent::Internal::exportStatsToChild`); `tags()` / `tagExtractedName()` are dropped. - The child's `StatMerger::mergeCounters` re-creates the stat from the name alone, which runs only regex tag extraction. With no matching `stats_tags` regex, the merged stat gets **empty tags** and `tagExtractedName == the full mangled name`. - That no-tags stat is created **before** the child's own code first touches the stat, so it wins the central-cache slot. The later tagged creation returns the already-mangled stat (stats are immutable post-creation). The tag values end up baked into the metric name with empty labels (e.g. as exported to Prometheus). This is the gap behind the long-standing `// TODO(snowp): Propagate tag values during hot restarts` in `stat_merger.cc`. Regex-extracted tags survive only because extraction re-derives them from the name; programmatic tags have nothing to re-derive from. This change actually propagates the tags: - `hot_restart.proto`: new `TaggedMetric` (tag-extracted name + repeated `Tag`) and `counter_tags` / `gauge_tags` maps on `Reply.Stats`. - The parent emits an entry **only for tags the child could not re-derive from the name**: it re-runs the store's `TagProducer` on the flat name and skips the stat when extraction reproduces the stored tags (the common case — including all default tag regexes). The stats transfer payload is therefore unchanged except for stats that actually carry programmatic tags. A nullable `Store::tagProducer()` accessor (default `nullptr`; only `ThreadLocalStoreImpl` overrides) supports the comparison. - The child decodes the metadata and `StatMerger` re-creates the stat with the original tags via new `Scope::counterFromMergedStatName` / `gaugeFromMergedStatName`. Following #45146 these have non-virtual-breaking defaults that delegate to the tag-aware `counterFromTaggedName` / `gaugeFromTaggedName` (which retain the metadata on tag-aware scopes and `IsolatedStoreImpl`); the legacy `ThreadLocalStore` `ScopeImpl` — which intentionally drops tag metadata on the `*FromTaggedName` path because it cannot compose tag-extracted names with its prefix in general — overrides them to honor the components, which arrive fully resolved. The full name is still reconstructed via `DynamicContext` (dynamic spans preserved), so the cache key matches the stat the child independently creates — the fix removes the first-write-wins poisoning rather than working around it. **Risk Level:** Medium — changes stats labels after a hot restart for tag-bearing stats. Runtime guarded. **Testing:** New tests: `stat_merger_test` (`ProgrammaticTagsSurviveMerge`, `ProgrammaticGaugeTagsSurviveMerge`, `ProgrammaticTagsLostWithoutMetadata` pinning the pre-fix symptom), `hot_restarting_parent_test` (`ExportsTagMetadataOnlyWhenNotRederivable`, `TagMetadataAppliedToMergedStats` end-to-end, `TagMetadataIgnoredWhenRuntimeFlagDisabled`), and `thread_local_store_test` (`MergedStatNameHonorsSuppliedTags` on both the legacy and tag-aware scopes). Built/run via RBE. **Docs Changes:** N/A **Release Notes:** Added (`changelogs/current/bug_fixes/stats__hot-restart-propagate-programmatic-stat-tags.rst`). **Runtime guard:** `envoy.reloadable_features.hot_restart_propagate_stat_tags` (revert to legacy name-derived behavior).", "url": "https://github.com/envoyproxy/envoy/pull/45674", "createdAt": "2026-06-16T23:12:06Z", "updatedAt": "2026-08-13T15:26:38Z", "timestamp": "2026-08-13T15:26:38Z", "metrics": { "reactions": 0, "comments": 14 }, "labels": [], "author": "bpalermo", "state": "open", "assignees": [ "wbpcode", "paul-r-gall" ], "change": "updated" } }, { "id": "event:f6db8e5e14d4e601151f", "signalId": "github:envoyproxy/envoy:pull_request:46673", "event": "changed", "observedAt": "2026-08-13T16:19:22.035158Z", "changedFields": [ "updatedAt" ], "signal": { "id": "github:envoyproxy/envoy:pull_request:46673", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "Order dependent bug", "text": "Commit Message: Fix flaky order-dependent stats_test failures via physical test file separation Additional Description: The tests `NonNumberValueFormatted` and `GaugeNonNumberValueFormatted` both trigger identical error logs emitted via `ENVOY_LOG_PERIODIC_MISC` in `stats.cc`. Because this macro rate-limits logging to prevent log spam, running these tests consecutively in the same target process led to one suppressing the other, causing flaky test failures under randomized execution ordering. Risk Level: low Testing: NA Docs Changes: NA Release Notes: NA Platform Specific Features: NA", "url": "https://github.com/envoyproxy/envoy/pull/46673", "createdAt": "2026-08-12T21:06:33Z", "updatedAt": "2026-08-13T15:20:30Z", "timestamp": "2026-08-13T15:20:30Z", "metrics": { "reactions": 0, "comments": 2 }, "labels": [], "author": "Wenwei-Zhao", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:ce808368e4ead47e858b", "signalId": "github:envoyproxy/envoy:pull_request:43255", "event": "changed", "observedAt": "2026-08-13T16:19:22.035158Z", "changedFields": [ "updatedAt" ], "signal": { "id": "github:envoyproxy/envoy:pull_request:43255", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "[WIP] bazel: Add compatibility stubs for bzlmod", "text": "this provides some of the compatibility required for bzlmod, without breaking workspace mode will follow up to fully enable bzlmod (as non-default in subsequent pr)", "url": "https://github.com/envoyproxy/envoy/pull/43255", "createdAt": "2026-02-01T01:15:57Z", "updatedAt": "2026-08-13T15:10:28Z", "timestamp": "2026-08-13T15:10:28Z", "metrics": { "reactions": 0, "comments": 3 }, "labels": [ "no stalebot", "deps", "ai:assisted" ], "author": "phlax", "state": "open", "assignees": [ "RyanTheOptimist" ], "change": "updated" } }, { "id": "event:ca582d2dcface51f7695", "signalId": "github:envoyproxy/envoy:pull_request:46682", "event": "changed", "observedAt": "2026-08-13T16:19:22.035158Z", "changedFields": [ "updatedAt" ], "signal": { "id": "github:envoyproxy/envoy:pull_request:46682", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "Restrict local reply streaming integration tests", "text": "... so that it runs only on Envoy gRPC Change-Id: If3ff45c3ee9db39b14ed506a7ef85ae00ec7db24 Commit Message: Additional Description: Risk Level: Testing: Docs Changes: Release Notes: Platform Specific Features: [Optional Runtime guard:] [Optional Fixes #Issue] [Optional Fixes commit #PR or SHA] [Optional Deprecated:] [Optional [API Considerations](https://github.com/envoyproxy/envoy/blob/main/api/review_checklist.md):]", "url": "https://github.com/envoyproxy/envoy/pull/46682", "createdAt": "2026-08-13T12:13:50Z", "updatedAt": "2026-08-13T15:02:57Z", "timestamp": "2026-08-13T15:02:57Z", "metrics": { "reactions": 0, "comments": 2 }, "labels": [], "author": "etruong42", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:979639cbfdc04a47b52b", "signalId": "github:envoyproxy/envoy:pull_request:46560", "event": "changed", "observedAt": "2026-08-13T16:19:22.035158Z", "changedFields": [ "updatedAt" ], "signal": { "id": "github:envoyproxy/envoy:pull_request:46560", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "Avoid excessive hashing for well-known header lookups", "text": " Commit Message: Additional Description: Risk Level: Testing: Docs Changes: Release Notes: Platform Specific Features: [Optional Runtime guard:] [Optional Fixes #Issue] [Optional Fixes commit #PR or SHA] [Optional Deprecated:] [Optional [API Considerations](https://github.com/envoyproxy/envoy/blob/main/api/review_checklist.md):]", "url": "https://github.com/envoyproxy/envoy/pull/46560", "createdAt": "2026-08-06T14:24:17Z", "updatedAt": "2026-08-13T14:51:50Z", "timestamp": "2026-08-13T14:51:50Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [], "author": "etruong42", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:4440958a68b1c3152ca5", "signalId": "github:envoyproxy/envoy:pull_request:46685", "event": "discovered", "observedAt": "2026-08-13T16:19:22.035158Z", "changedFields": [], "signal": { "id": "github:envoyproxy/envoy:pull_request:46685", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "Create Snapshot of runtime stats before incrementing counter", "text": "The stats_.load_success_ counter is incremented before the Snapshot of runtime metrics is taken. This leads to a small window where a client can request runtime metrics after load_success_ counter indicates a successful load but before the latest runtime metrics are available. Change-Id: Iac433fdf7637eec59186cfa44f2e065d367fc73f Commit Message: Additional Description: Risk Level: Testing: Docs Changes: Release Notes: Platform Specific Features: [Optional Runtime guard:] [Optional Fixes #Issue] [Optional Fixes commit #PR or SHA] [Optional Deprecated:] [Optional [API Considerations](https://github.com/envoyproxy/envoy/blob/main/api/review_checklist.md):]", "url": "https://github.com/envoyproxy/envoy/pull/46685", "createdAt": "2026-08-13T14:48:02Z", "updatedAt": "2026-08-13T14:49:08Z", "timestamp": "2026-08-13T14:49:08Z", "metrics": { "reactions": 0, "comments": 2 }, "labels": [], "author": "etruong42", "state": "open", "assignees": [], "change": "new" } }, { "id": "event:dd3e2185486b25c40944", "signalId": "github:envoyproxy/envoy:pull_request:46613", "event": "changed", "observedAt": "2026-08-13T16:19:22.035158Z", "changedFields": [ "updatedAt", "metrics", "assignees" ], "signal": { "id": "github:envoyproxy/envoy:pull_request:46613", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "network: send zero-length UDP datagrams", "text": "Preserve empty datagrams across all UDP send paths. Justification: RFC 768 permits UDP datagrams with an empty payload: the minimum UDP Length is 8 octets, corresponding to the UDP header alone. Envoy currently treats these valid datagrams as no-op writes and silently drops them. This change ensures they reach the socket send operation for connected and unconnected UDP sockets. Commit Message: Additional Description: Risk Level: Testing: Done Docs Changes: Release Notes: Platform Specific Features:", "url": "https://github.com/envoyproxy/envoy/pull/46613", "createdAt": "2026-08-10T13:37:06Z", "updatedAt": "2026-08-13T14:42:44Z", "timestamp": "2026-08-13T14:42:44Z", "metrics": { "reactions": 0, "comments": 2 }, "labels": [], "author": "nezdolik", "state": "open", "assignees": [ "kyessenov", "agrawroh" ], "change": "updated" } }, { "id": "event:f7e86554f5cf577576d7", "signalId": "github:envoyproxy/envoy:pull_request:46672", "event": "changed", "observedAt": "2026-08-13T16:19:22.035158Z", "changedFields": [ "updatedAt" ], "signal": { "id": "github:envoyproxy/envoy:pull_request:46672", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "[draft] dym: go sdk for udp listener filter", "text": " Commit Message: Additional Description: Risk Level: Testing: Docs Changes: Release Notes: Platform Specific Features: [Optional Runtime guard:] [Optional Fixes #Issue] [Optional Fixes commit #PR or SHA] [Optional Deprecated:] [Optional [API Considerations](https://github.com/envoyproxy/envoy/blob/main/api/review_checklist.md):]", "url": "https://github.com/envoyproxy/envoy/pull/46672", "createdAt": "2026-08-12T21:04:40Z", "updatedAt": "2026-08-13T14:11:02Z", "timestamp": "2026-08-13T14:11:02Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [], "author": "ovadiagal", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:d9983e912280cd71a67d", "signalId": "github:envoyproxy/envoy:pull_request:45073", "event": "discovered", "observedAt": "2026-08-13T16:19:22.035158Z", "changedFields": [], "signal": { "id": "github:envoyproxy/envoy:pull_request:45073", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "c-ares: make qcache_max_ttl configurable", "text": "Commit Message: c-ares: make qcache_max_ttl configurable Additional Description: expose the qcache_max_ttl setting and share DNSResolver if cares config is the same so the qcache can be shared. runtime guard \"envoy.restart_features.shared_cares_dns_resolver\" is set to true by default to enable sharing DNSResolver if cares config of the clusters are the same. Set to false to disable this behavior. AI is used to generate the tests and write some of the comment but I did review and tune/modify all the tests added. All other code are hand written. Risk Level: Low Testing: unit test and manual test using tcpdump to verify multiple clusters with the same host (different port) only generate 1 dns lookup most of the time. Docs Changes: None Release Notes: Added qcache_max_ttl field to CaresDnsResolverConfig Platform Specific Features: None [Optional Runtime guard:] \"envoy.restart_features.shared_cares_dns_resolver\" is set to true by default to enable sharing DNSResolver if cares config of the clusters are the same. Set to false to disable this behavior.", "url": "https://github.com/envoyproxy/envoy/pull/45073", "createdAt": "2026-05-14T17:09:02Z", "updatedAt": "2026-08-13T13:54:26Z", "timestamp": "2026-08-13T13:54:26Z", "metrics": { "reactions": 0, "comments": 15 }, "labels": [], "author": "andy-fong", "state": "closed", "assignees": [ "yanavlasov", "markdroth" ], "change": "new" } }, { "id": "event:2a715a4529a67e6f4af1", "signalId": "github:envoyproxy/envoy:pull_request:46308", "event": "changed", "observedAt": "2026-08-13T16:19:22.035158Z", "changedFields": [ "updatedAt" ], "signal": { "id": "github:envoyproxy/envoy:pull_request:46308", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "composite: fail over to the next sub-cluster when a sub-cluster has no hosts", "text": "## Commit Message composite: fail over to the next sub-cluster when a sub-cluster has no hosts The composite cluster failed a request with 503 no_healthy_upstream when the sub-cluster mapped to the current attempt had no host available, for example because DNS resolution returned an empty endpoint list or because all of its hosts had been ejected. Host selection now advances to the following sub-clusters in the configured list within the same attempt, and only fails when none of them can provide a host. Guarded by `envoy.reloadable_features.composite_cluster_skip_clusters_without_hosts`. ## Additional Description ### Documented behavior vs. actual behavior The `composite_cluster` [docs](https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/upstream/composite_cluster) stated: > *\"If a selected sub-cluster has no healthy hosts available, the request will fail according to that sub-cluster's load balancing behavior, **potentially triggering another retry attempt if configured**.\"* In practice that retry path was unreachable: `no_healthy_upstream` is a routing-level rejection raised before any upstream connection attempt, and no `retry_on` condition covers it. A composite cluster whose first sub-cluster had zero endpoints failed with `503 no_healthy_upstream` regardless of the retry policy, so per-request failover did not work at all in that scenario. ### Change from the previous revision of this PR The first revision of this PR added a core `no-healthy-upstream` retry condition (`RETRY_ON_NO_HEALTHY_UPSTREAM`) plus a hook in `Filter::createConnPoolOrHandleFailure()`. Per review feedback from @wbpcode and @agrawroh, that a core feature serving one extension is the wrong layer, and that the composite cluster should pick a sub-cluster that has healthy hosts itself. The previous approach has been fully reverted and the fix now lives entirely in the extension. Reverted back to `main`: `envoy/router/router.h`, `source/common/http/headers.h`, `source/common/router/retry_state_impl.{h,cc}`, `source/common/router/router.cc`, `test/common/router/{router_test,retry_state_impl_test}.cc`, `test/mocks/router/mocks.{h,cc}`, `api/envoy/config/route/v3/route_components.proto`, `docs/root/configuration/http/http_filters/router_filter.rst`. ### Fix `CompositeClusterLoadBalancer::chooseHost()` still maps the attempt count to a starting cluster index, but host selection now runs through a new `selectHostWithFailover()` helper that walks forward from that index: * A sub-cluster is skipped when it is not present in the cluster manager, or when its load balancer returns no host. * Selection returns immediately when a host is selected, or when the sub-cluster started asynchronous host selection (`HostSelectionResponse::cancelable` set), so an in-flight async selection is not abandoned or duplicated. * When no sub-cluster can provide a host, the `details` and `failure_status` of the last sub-cluster tried are propagated, so the resulting local reply keeps the same diagnostics as before. Availability is determined by asking the sub-cluster's load balancer rather than by inspecting its priority set, so nested composite/aggregate sub-clusters, `CLUSTER_PROVIDED` sub-clusters, panic mode and override-host behavior all keep working. When a sub-cluster can serve the attempt, its load balancer is the only one invoked, so there are no wasted host selections on the happy path. ### Behavior notes * Selection remains driven by the attempt count: an attempt that failed over to a later sub-cluster does not shift the mapping of subsequent attempts. With `[primary, secondary, fallback]` and an empty `primary`, attempt 1 uses `secondary` and attempt 2 also maps to `secondary`. This is documented in the arch overview. If reviewers prefer that a failover also advance the following attempts, that can be done by recording the used index in filter state — happy to add it here or as a follow-up. * `peekAnotherHost()` and `selectExistingConnection()` keep the plain attempt mapping. Every in-tree `selectExistingConnection()` implementation returns `nullopt`, so there is no practical mismatch, and prefetching does not need the failover. ### Minimal reproduction A minimal Docker Compose reproduction of the original bug is available at: https://github.com/JonSchaeffer/playground/tree/main/envoy/composite-bug-minimal-repro ## Risk Level Low — the change is scoped to the composite cluster extension, and it is behind a reloadable runtime guard. ## Testing * Unit tests in `test/extensions/clusters/composite/cluster_test.cc`: failover when the selected sub-cluster has no host, failover when the selected sub-cluster is missing from the cluster manager, no host plus preserved failure details when no sub-cluster can serve the request, asynchronous host selection returned without trying other sub-clusters, and legacy behavior with the runtime guard disabled. * Integration tests in `test/extensions/clusters/composite/cluster_integration_test.cc`: failover with `num_retries: 0` (proving no retry is involved), failover across two consecutive sub-clusters without endpoints, `503` when no sub-cluster has endpoints, and `503` with the runtime guard disabled. The two `no-healthy-upstream` retry tests from the previous revision were removed. * Format and spelling checks: `bazel run //tools/code_format:check_format` and `bazel run //tools/spelling:check_spelling_pedantic` both pass. ## Docs Changes * `docs/root/intro/arch_overview/upstream/composite_cluster.rst`: new \"Hosts availability\" section, updated the sub-cluster health / deterministic routing considerations, and documented the runtime guard and the attempt-progression caveat. * `api/envoy/extensions/clusters/composite/v3/cluster.proto`: comment-only update describing the failover. No field or type changes. ## Release Notes `changelogs/current/bug_fixes/composite_cluster__skip-clusters-without-hosts.rst`. ## Runtime guard `envoy.reloadable_features.composite_cluster_skip_clusters_without_hosts` (enabled by default). Setting it to `false` restores the previous behavior of failing the attempt when the sub-cluster mapped to that attempt has no host available. --- > **Note:** This PR was developed with AI assistance (Claude). The author has reviewed and > understands all changes.", "url": "https://github.com/envoyproxy/envoy/pull/46308", "createdAt": "2026-07-22T12:31:41Z", "updatedAt": "2026-08-13T13:51:19Z", "timestamp": "2026-08-13T13:51:19Z", "metrics": { "reactions": 0, "comments": 9 }, "labels": [ "api" ], "author": "JonSchaeffer", "state": "open", "assignees": [ "agrawroh", "wbpcode" ], "change": "updated" } }, { "id": "event:07d3fff5c5ab82bdc526", "signalId": "github:envoyproxy/envoy:pull_request:46543", "event": "changed", "observedAt": "2026-08-13T17:43:20.785491Z", "changedFields": [ "updatedAt", "metrics" ], "signal": { "id": "github:envoyproxy/envoy:pull_request:46543", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "mcp_transcoder: Fix Unbounded Recursion DoS", "text": "Commit Message: mcp_transcoder: Fix Unbounded Recursion DoS Additional Description: This PR limits the maximum nesting depth for JSON query parameter processing in constructQueryParams to 100, which mitigates a stack overflow condition caused by maliciously crafted, deeply nested query parameters. Risk Level: Low Testing: Unit tests. Docs Changes: N/A Release Notes: N/A Platform Specific Features: N/A", "url": "https://github.com/envoyproxy/envoy/pull/46543", "createdAt": "2026-08-04T19:18:20Z", "updatedAt": "2026-08-13T17:42:38Z", "timestamp": "2026-08-13T17:42:38Z", "metrics": { "reactions": 0, "comments": 6 }, "labels": [], "author": "guoyilin42", "state": "open", "assignees": [ "tyxia" ], "change": "updated" } }, { "id": "event:97bb2f6bad662aea819a", "signalId": "github:envoyproxy/envoy:pull_request:46673", "event": "changed", "observedAt": "2026-08-13T17:43:20.785491Z", "changedFields": [ "updatedAt", "metrics", "assignees" ], "signal": { "id": "github:envoyproxy/envoy:pull_request:46673", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "Order dependent bug", "text": "Commit Message: Fix flaky order-dependent stats_test failures via physical test file separation Additional Description: The tests `NonNumberValueFormatted` and `GaugeNonNumberValueFormatted` both trigger identical error logs emitted via `ENVOY_LOG_PERIODIC_MISC` in `stats.cc`. Because this macro rate-limits logging to prevent log spam, running these tests consecutively in the same target process led to one suppressing the other, causing flaky test failures under randomized execution ordering. Risk Level: low Testing: NA Docs Changes: NA Release Notes: NA Platform Specific Features: NA", "url": "https://github.com/envoyproxy/envoy/pull/46673", "createdAt": "2026-08-12T21:06:33Z", "updatedAt": "2026-08-13T17:40:18Z", "timestamp": "2026-08-13T17:40:18Z", "metrics": { "reactions": 0, "comments": 4 }, "labels": [], "author": "Wenwei-Zhao", "state": "open", "assignees": [ "adisuissa", "antoniovleonti" ], "change": "updated" } }, { "id": "event:c8093d051386714f83f5", "signalId": "github:envoyproxy/envoy:pull_request:46502", "event": "changed", "observedAt": "2026-08-13T17:43:20.785491Z", "changedFields": [ "updatedAt" ], "signal": { "id": "github:envoyproxy/envoy:pull_request:46502", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "Support hot restart handoff for connectionless UDP flows", "text": "Commit Message: udp: Support hot restart handoff for connectionless UDP flows Additional Description: The parent instance keeps serving established UDP flows while draining and forwards packets of unknown flows to the child over the hot restart RPC, instead of going dark between drain start and parent shutdown. Risk Level: Medium Testing: Added unit and integration tests, manual Docs Changes: - Added `envoy.resource_limits.listener..udp_flow_limit`. - Added `downstream_flows_active, Gauge`, if equal to the limit, flows might get misrouted during hotrestart Release Notes: Added new_features entry Platform Specific Features: N/A Fixes #34732", "url": "https://github.com/envoyproxy/envoy/pull/46502", "createdAt": "2026-08-01T12:28:12Z", "updatedAt": "2026-08-13T17:36:12Z", "timestamp": "2026-08-13T17:36:12Z", "metrics": { "reactions": 0, "comments": 7 }, "labels": [ "api" ], "author": "filipcacky", "state": "open", "assignees": [ "nezdolik", "markdroth" ], "change": "updated" } }, { "id": "event:00acc1690a4fb0c1ed03", "signalId": "github:envoyproxy/envoy:pull_request:46318", "event": "changed", "observedAt": "2026-08-13T17:43:20.785491Z", "changedFields": [ "updatedAt", "metrics" ], "signal": { "id": "github:envoyproxy/envoy:pull_request:46318", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "ext_proc: adding direct mode_override support", "text": "This is a follow up implementation for https://github.com/envoyproxy/envoy/pull/46315", "url": "https://github.com/envoyproxy/envoy/pull/46318", "createdAt": "2026-07-22T21:30:10Z", "updatedAt": "2026-08-13T17:31:37Z", "timestamp": "2026-08-13T17:31:37Z", "metrics": { "reactions": 0, "comments": 11 }, "labels": [ "api" ], "author": "yanjunxiang-google", "state": "open", "assignees": [ "stevenzzzz", "adisuissa", "yanavlasov", "rshriram", "tyxia" ], "change": "updated" } }, { "id": "event:1b32e72dbc606f74cdf6", "signalId": "github:envoyproxy/envoy:pull_request:46526", "event": "discovered", "observedAt": "2026-08-13T17:43:20.785491Z", "changedFields": [], "signal": { "id": "github:envoyproxy/envoy:pull_request:46526", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "router: support building an SRDS scope key from filter state", "text": "**Commit Message:** support building an SRDS scope key from filter state **Additional Description:** Scope keys could only be built from a request header. This adds a `filter_state` fragment type so a scope key can be built from a filter state object instead. This matters when the value selecting the route table is known at connection time: a network filter can store it in filter state, but a header set by an HTTP filter arrives after the filter chain is created, which is too late for per-route filter config. Connection life span objects are reachable from the stream, so a filter-state fragment resolves the scope on the first route resolution. Risk Level: Low Testing: Unit and Integration tests Docs Changes: Changelog added Release Notes: N.A Platform Specific Features: N.A", "url": "https://github.com/envoyproxy/envoy/pull/46526", "createdAt": "2026-08-04T02:17:18Z", "updatedAt": "2026-08-13T17:31:19Z", "timestamp": "2026-08-13T17:31:19Z", "metrics": { "reactions": 0, "comments": 5 }, "labels": [], "author": "basundhara-c", "state": "open", "assignees": [ "adisuissa", "markdroth", "botengyao" ], "change": "new" } }, { "id": "event:c5f8278d7b3380c7552b", "signalId": "github:envoyproxy/envoy:pull_request:46686", "event": "discovered", "observedAt": "2026-08-13T17:43:20.785491Z", "changedFields": [], "signal": { "id": "github:envoyproxy/envoy:pull_request:46686", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "Add support for `serverNameOverride` in ALTS and create `ServerNameDecoratorTransportSocketOptions`", "text": "Commit Message: support `serverNameOverride` in ALTS and add `ServerNameDecoratingTransportSocketOptions` Additional Description: These two changes are in pursuit of eventually being able to pass the original target name to the TransportSocket 1) Create `ServerNameDecoratingTransportSocketOptions` as a `TransportSocketOptions` wrapper class that populates the `serverNameOverride` value. 2) Modify ALTS Transport Socket Options to use the `serverNameOverride` value and pass this `target_value` in to `StartHandshakeReq` Risk Level: Low (Creating decorator class in core network, and only new optional ALTS behavior with no-op defaults). Testing: `transport_socket_options_impl_test.cc` additions for `ServerNameDecoratingTransportSocketOptions`, `alts_proxy_test.cc`, `alts_tsi_handshaker_test.cc`, `tsi_socket_test.cc`, and `config_test.cc` for ALTS Transport Socket behavioral changes Docs Changes: n/a Release Notes: n/a Platform Specific Features: n/a", "url": "https://github.com/envoyproxy/envoy/pull/46686", "createdAt": "2026-08-13T16:56:41Z", "updatedAt": "2026-08-13T16:56:47Z", "timestamp": "2026-08-13T16:56:47Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [], "author": "MichaelHDing", "state": "open", "assignees": [], "change": "new" } }, { "id": "event:09fda104b67e9c598fac", "signalId": "github:envoyproxy/envoy:pull_request:46679", "event": "changed", "observedAt": "2026-08-13T17:43:20.785491Z", "changedFields": [ "updatedAt" ], "signal": { "id": "github:envoyproxy/envoy:pull_request:46679", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "Add extension point to OpenTelemetry tracer for custom exporters.", "text": " ### Commit Message Added support for custom exporters in the OpenTelemetry tracer. In implementing this feature, I also changed some existing code in opentelemetry_tracer_impl.cc to make it more thread safe, such as moving the instantiation of the gRPC client factory out of the worker threads and into the main thread. This means that if the factory creation returns an error, it won't crash the worker thread, and thereby the whole Envoy proxy. ### Additional Description AI was used to generate the code and tests in this PR. I have reviewed – and fully understand – the code. ### Risk Level Low ### Testing I've added unit tests testing both the control plane and data plane code flows. ### Docs Changes None required ### Release Notes Added a changelog under new_features (area: tracing) ### Platform Specific Features None", "url": "https://github.com/envoyproxy/envoy/pull/46679", "createdAt": "2026-08-13T07:48:06Z", "updatedAt": "2026-08-13T16:44:58Z", "timestamp": "2026-08-13T16:44:58Z", "metrics": { "reactions": 0, "comments": 2 }, "labels": [ "api" ], "author": "jakebennert", "state": "open", "assignees": [ "mattklein123" ], "change": "updated" } }, { "id": "event:a64eabd562f0cfd51eb3", "signalId": "github:envoyproxy/envoy:pull_request:46658", "event": "discovered", "observedAt": "2026-08-13T17:47:07.884300Z", "changedFields": [], "signal": { "id": "github:envoyproxy/envoy:pull_request:46658", "source": "github", "group": "platform-infrastructure", "project": "envoyproxy/envoy", "kind": "pull_request", "title": "tls_inspector: fix GREASE filtering in JA4_c signature algorithms", "text": "## Summary The JA4 fingerprint's third component hashes the ClientHello's extension list joined to its `signature_algorithms` list. Per the [JA4 spec](https://github.com/FoxIO-LLC/ja4/blob/main/technical_details/JA4.md), GREASE codepoints must be excluded everywhere they appear — including in `signature_algorithms`. `getJA4ExtensionHash` already applies `isNotGrease` to extension type IDs, and `getJA4CipherHash`, `countCiphers`, and `countExtensions` apply it to their respective inputs. The `signature_algorithms` collection loop was the sole exception, pushing every 16-bit codepoint from the extension body unconditionally. Clients that inject a GREASE value into `signature_algorithms` (e.g. Chrome's per-handshake random GREASE selection, drawn from the 16 reserved code points `0x0a0a`, `0x1a1a`, …, `0xfafa`) therefore produce a **different** JA4_c hash per connection while all other parts of the fingerprint are identical — resulting in many-to-one hash collapse when compared against spec-compliant implementations. ## Fix Guard the `sig_algs.push_back(sig_alg)` call in `getJA4ExtensionHash` with `isNotGrease(sig_alg)`, matching the treatment already applied everywhere else in the file. ## Test plan - [x] Added `TEST(JA4Fingerprinter, GreaseValueFilteredFromSignatureAlgorithms)` in `ja4_fingerprint_test.cc` that constructs two \\`SSL_CLIENT_HELLO\\`s identical except for a GREASE codepoint (\\`0x0a0a\\`) in \\`signature_algorithms\\` and asserts \\`JA4Fingerprinter::create\\` produces the same fingerprint for both. - [x] \\`bazel test //test/extensions/filters/listener/tls_inspector:ja4_fingerprint_test\\` passes locally. ## Notes - No existing entry in the \\`JA4_TEST_VECTORS\\` table in \\`tls_inspector_ja4_test.cc\\` contains a GREASE codepoint inside its \\`signature_algorithms\\` extension body — all GREASE bytes in those captures live in extensions/versions/keyshare slots, which are already filtered correctly — so its pinned expected hashes remain valid. - This change was drafted with AI assistance and reviewed by the author.", "url": "https://github.com/envoyproxy/envoy/pull/46658", "createdAt": "2026-08-11T22:04:01Z", "updatedAt": "2026-08-13T17:45:55Z", "timestamp": "2026-08-13T17:45:55Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [], "author": "dangle1", "state": "open", "assignees": [], "change": "new" } } ] } }