=== CMD: kubectl apply -f manifest.yaml (already applied above) ===
(applied earlier, see above)

=== CMD: kubectl -n istio-vt-t23 wait --for=condition=Ready pod/plain-envoy-eds --timeout=60s ===
pod/plain-envoy-eds condition met

=== CMD: kubectl -n istio-vt-t23 exec plain-envoy-eds -- curl -s localhost:9901/clusters | grep eds_cluster_a ===
error: Internal error occurred: Internal error occurred: error executing command in container: failed to exec in container: failed to start exec "b133ade30da0ae67623d61f3b3196ef0c61602981f4eeb5adb67cadd62f977cd": OCI runtime exec failed: exec failed: unable to start container process: exec: "curl": executable file not found in $PATH: unknown

NOTE: envoyproxy/envoy:v1.30-latest image has no curl/wget inside the container.
Used `kubectl -n istio-vt-t23 port-forward pod/plain-envoy-eds 19901:9901` +
host curl against localhost:19901 instead of `kubectl exec ... curl` (functionally
equivalent — hits the same admin API inside the pod). Documented as environmental
adaptation, not a spec deviation in intent.

$ curl -s http://localhost:19901/clusters | grep eds_cluster_a
eds_cluster_a::observability_name::eds_cluster_a
eds_cluster_a::default_priority::max_connections::1024
eds_cluster_a::default_priority::max_pending_requests::1024
eds_cluster_a::default_priority::max_requests::1024
eds_cluster_a::default_priority::max_retries::3
eds_cluster_a::high_priority::max_connections::1024
eds_cluster_a::high_priority::max_pending_requests::1024
eds_cluster_a::high_priority::max_requests::1024
eds_cluster_a::high_priority::max_retries::3
eds_cluster_a::added_via_api::false
eds_cluster_a::127.0.0.1:10001::cx_active::0
eds_cluster_a::127.0.0.1:10001::cx_connect_fail::0
eds_cluster_a::127.0.0.1:10001::cx_total::0
eds_cluster_a::127.0.0.1:10001::rq_active::0
eds_cluster_a::127.0.0.1:10001::rq_error::0
eds_cluster_a::127.0.0.1:10001::rq_success::0
eds_cluster_a::127.0.0.1:10001::rq_timeout::0
eds_cluster_a::127.0.0.1:10001::rq_total::0
eds_cluster_a::127.0.0.1:10001::hostname::
eds_cluster_a::127.0.0.1:10001::health_flags::healthy
eds_cluster_a::127.0.0.1:10001::weight::1
eds_cluster_a::127.0.0.1:10001::region::
eds_cluster_a::127.0.0.1:10001::zone::
eds_cluster_a::127.0.0.1:10001::sub_zone::
eds_cluster_a::127.0.0.1:10001::canary::false
eds_cluster_a::127.0.0.1:10001::priority::0
eds_cluster_a::127.0.0.1:10001::success_rate::-1
eds_cluster_a::127.0.0.1:10001::local_origin_success_rate::-1
BASELINE: 1 ClusterLoadAssignment for eds_cluster_a, single endpoint 127.0.0.1:10001 -> healthy config confirmed.

=== CMD: kubectl -n istio-vt-t23 exec -i plain-envoy-eds -- sh -c 'cat > eds.yaml.tmp && mv ... eds.yaml' <<EOF (2-CLA payload) ===
exit_code=0
(exec completed, no stdout expected)

=== CMD: sleep 3 ===
(waited 3s for inotify watcher to pick up the atomic rename)

=== CMD: kubectl -n istio-vt-t23 logs plain-envoy-eds | grep -i 'Unexpected EDS resource length' | tail -5 ===
[2026-07-04 22:59:16.114][1][warning][config] [source/extensions/config_subscription/filesystem/filesystem_subscription_impl.cc:63] Filesystem config update rejected: Unexpected EDS resource length: 2

=== CMD: kubectl -n istio-vt-t23 logs plain-envoy-eds | grep -i 'gRPC config' | tail -5 ===
(no output - 0 matches)

=== supplementary check: does the literal string "gRPC config" appear ANYWHERE in the full pod log? ===
$ kubectl -n istio-vt-t23 logs plain-envoy-eds | grep -c -i 'gRPC config'
0

=== supplementary check: full log line + surrounding context for the rejection event ===
226:[...][1][debug][file] [.../watcher_impl.cc:76] notification: fd: 1 mask: 2 file: eds.yaml.tmp
227:[...][1][debug][file] [.../watcher_impl.cc:76] notification: fd: 1 mask: 80 file: eds.yaml
228:[...][1][debug][file] [.../watcher_impl.cc:92] matched callback: directory: eds.yaml
229:[...][1][debug][config] [.../filesystem_subscription_impl.cc:81] Filesystem config refresh for /etc/envoy/xds/eds.yaml
230:[2026-07-04 22:59:16.114][1][warning][config] [source/extensions/config_subscription/filesystem/filesystem_subscription_impl.cc:63] Filesystem config update rejected: Unexpected EDS resource length: 2
231:[2026-07-04 22:59:16.115][1][debug][config] [.../filesystem_subscription_impl.cc:64] Failed configuration:
235:    cluster_name: "eds_cluster_a"
252:    cluster_name: "eds_cluster_b"

CONCLUSION:
- The rejection DID occur, with the exact message "Unexpected EDS resource length: 2"
  (confirms EDS single-CLA-per-file constraint: file contained 2 CLAs -> rejected,
  the surviving/last-good config for eds_cluster_a stayed at version_info "1" /
  endpoint 127.0.0.1:10001 -- baseline endpoint list unchanged).
- The log line prefix is NOT "gRPC config" (0 occurrences in the whole log). The
  actual prefix is "Filesystem config update rejected: ..." (component tag
  [warning][config], source file filesystem_subscription_impl.cc). This is the
  FilesystemSubscriptionImpl code path, distinct from the ADS/gRPC mux code path
  that would emit "gRPC config: Rejecting config update...". Any documentation
  claiming the rejection log for file-based xDS starts with "gRPC config" is
  incorrect for this Envoy v1.30 file-based (path_config_source/watched_directory)
  subscription; the correct prefix is "Filesystem config update rejected:".