test(e2e): a sort key that can be absent fails the whole event read, in fourteen places #3712

kubectl get events --sort-by=.lastTimestamp does not skip an item that lacks the key. It fails the entire read with error: couldn't find any field with path "{.lastTimestamp}". An Event written through events.k8s.io/v1 surfaces in the core API with .lastTimestamp unset, so a single such Event in the namespace is enough to turn the whole listing into one error line.

That form appears fourteen times across eight files:

git grep -n "sort-by=.lastTimestamp" origin/main -- hack/ .github/

None of the fourteen is silent, and that is worth stating plainly because it bounds the severity. Every one of them keeps the reason somewhere a reader can find it. What none of them keeps is the events.

So the finding is this: the tool answers with a refusal instead of data at exactly the moment the data is being asked for because something already failed. A step dumping events after a failed install prints an error where the events would be, and telling that apart from a namespace with nothing to report takes knowing this particular behaviour.

The fix is the same everywhere. kubectl events is a separate subcommand, orders by last seen by default, and carries no --sort-by at all, so the failure has nowhere to come from. It is present in the client this repository pins for the sandbox, 1.33.13 in packages/core/testing/images/e2e-sandbox/Dockerfile; anywhere it would run against a different client that needs checking first. Where the subcommand does not fit, --sort-by=.metadata.creationTimestamp cannot be absent, at the price of ordering by creation instead of by last occurrence, which pushes a long repeating condition out of a tail window.

Not established: I did not reproduce the failure against a live cluster. I designed against the known behaviour and modelled it in a test stub. What I did check, one by one, is the fourteen call sites and how each of them handles a failed read.