e2e: a list truncated mid-record parses as a valid record in the dataplane capture filters #3660

Summary

Both record filters in hack/e2e-capture-dataplane.sh, lb_filter_services (line 117 at 605030b) and pod_filter_affected (line 210), select rows by field VALUES and never check the field COUNT, so a list that was cut off mid-record parses as a valid record. Demonstrated with stubs: a Service list truncated in the middle of an IP yields an lb-tenant-db.txt probing ip=192.0.2.5 for a service whose real IP was longer, plus a "reachable, skipped" verdict about an address that does not exist; a pod list truncated mid-record invents a node-<node>.txt for a half-parsed node name.

Why it matters

A truncated list is exactly what a bounded or interrupted read produces, and the capture's whole recent hardening is about making such reads honest. A half-record that parses as a record defeats that from below: the artifact then contains confidently-labelled data about objects that are artifacts of the cut, not of the cluster.

Fix shape

One guard per filter: NF == 7 in lb_filter_services, NF == 6 in pod_filter_affected (the jsonpath emits a fixed field count per record), dropping any row with fewer fields. The cut-off note machinery already added to this script explains WHY a row went missing, so dropping the fragment loses nothing a reader needs.