hack/e2e-capture-dataplane.sh:687 builds the per-pod capture path by joining namespace and pod name with a hyphen:
pf="$OUT/pod-$ns-$pod.txt"
Hyphens are legal in both, and neither is escaped, so distinct pods can map to the same file. Namespace a-b with pod c and namespace a with pod b-c both produce pod-a-b-c.txt. The capture opens it with >, so the second pod silently overwrites the first, and the artifact ends up describing one pod under a name that reads as if it covered both.
Low likelihood on the namespaces this collector actually runs against, and nothing observed. Recording it because the failure is silent and costs evidence on exactly the run where evidence is the point: the file exists, it is well-formed, and nothing reports that a capture was lost.
Two things make it worth a little more than it was. A healthy-pod reference is now written into the same per-pod file, so a collision loses the baseline too. And node-<node>.txt on line 522 has no such problem, since a node name is a single DNS label, which makes the pod path the only one of the two that can collide.
Fix: separate the two components with a character that cannot appear in either (a slash implies a subdirectory, so something like __ or percent-encoding), or hash the pair. Whatever the separator, worth a test that two pods whose joined names would collide produce two files.
The same file is also truncated between capture runs, while its companion is not. pod-<ns>-<pod>.txt is written with > (line 767), so a second capture of the same pod in the same output directory replaces the first. capture-notes.txt next to it is written with >> and even prints a --- new capture run --- separator when it already has content, so the notes accumulate across runs while the per-pod evidence they annotate does not. A reader who finds notes from two runs and pod files from one has no way to tell which run the surviving file belongs to.
hack/e2e-capture-dataplane.sh:687builds the per-pod capture path by joining namespace and pod name with a hyphen:pf="$OUT/pod-$ns-$pod.txt"Hyphens are legal in both, and neither is escaped, so distinct pods can map to the same file. Namespace
a-bwith podcand namespaceawith podb-cboth producepod-a-b-c.txt. The capture opens it with>, so the second pod silently overwrites the first, and the artifact ends up describing one pod under a name that reads as if it covered both.Low likelihood on the namespaces this collector actually runs against, and nothing observed. Recording it because the failure is silent and costs evidence on exactly the run where evidence is the point: the file exists, it is well-formed, and nothing reports that a capture was lost.
Two things make it worth a little more than it was. A healthy-pod reference is now written into the same per-pod file, so a collision loses the baseline too. And
node-<node>.txton line 522 has no such problem, since a node name is a single DNS label, which makes the pod path the only one of the two that can collide.Fix: separate the two components with a character that cannot appear in either (a slash implies a subdirectory, so something like
__or percent-encoding), or hash the pair. Whatever the separator, worth a test that two pods whose joined names would collide produce two files.The same file is also truncated between capture runs, while its companion is not.
pod-<ns>-<pod>.txtis written with>(line 767), so a second capture of the same pod in the same output directory replaces the first.capture-notes.txtnext to it is written with>>and even prints a--- new capture run ---separator when it already has content, so the notes accumulate across runs while the per-pod evidence they annotate does not. A reader who finds notes from two runs and pod files from one has no way to tell which run the surviving file belongs to.