Change:
if IsPodActive(p) { result = append(result, p) } else { <del> logger.V(4).Info("Ignoring inactive pod", "pod", klog.KObj(p), "phase", p.Status.Phase, "deletionTime", p.DeletionTimestamp) </del> <ins> logger.V(4).Info("Ignoring inactive pod", "pod", klog.KObj(p), "phase", p.Status.Phase, "deletionTime", klog.SafePtr(p.DeletionTimestamp)) </ins> } } return result

Discussion:
Job controller, and possibly other controllers keep logging panics from this line in : This happens during e2e tests, and I think it happens on production as well. Here is an example for the successful build: 2023-10-20T09:10:28.016158573Z stderr F I1020 09:10:28. 1 ] "Ignoring inactive pod" pod="ttlafterfinished-3394/rand-non-local-ghcvx" phase="Failed" deletionTime="&lt;panic: runtime error: invalid memory address or nil pointer dereference" No panics during e2e test from this line in . Run e2e or integration tests for the job controller. No response <details</details<detailsReproducible on kind during e2e tests </details<details</details<details</details<details</details<details</details
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/sig apps FYI
Do you have any idea which variable is nil here?
oops, sorry, it's the deletionTimestamp
Is it actually a panic though? It seems that the logger is parsing a nil value as and proceeding. I think we could use and provide a default value. /priority important-longterm
Possibly this is just logger indeed. Still it is important imo because it makes looking for real panics in logs hard. This was my use case to understand another issue.
The logger sees an (= ) value which implements and calls it's method - in this case, ;l=527. That then panics. We've gone back and forth whether the logging call should try to call the method and recover from a panic or try to do some advance checks whether the value is perhaps nil. There could be implementations for pointers which produce some nice output for , so not calling it would be a loss.

Also, detecting nil values is surprisingly hard, if I remember correctly (the interface is non-nil, only the value hidden inside it is)), therefore currently the code simply calls it.
I can work of this /assign
how do you want to solve this? Besides some potential klog improvement, fixing to not crash for a nil pointer would be good. already does this.
Hi ! Sorry I didn't answer yesterday. I like the idea of doing the check at type level and we already have a precedent. Should we provide a default value as suggests? Tbh I'm not sure what would be a a proper default value here
When logging an object's , "is nil" is the right information to log when the pointer is nil. There is no default that can or should be used instead.
I've raised a PR with a simple fix. I've run the integration tests locally and it fixes the problem. Let me know if that's enough Thanks!
the changes in have been merged but not yet released (). what's the klog release cycle? It seems that there's no clear release schedule, right?
We usually do one release for each Kubernetes release, if there are changes.
However, in this case the next release this could go into is 1.30, right? This would be unfortunate because we wouldn't be able to fix 1.29 with the klog changes. If this is the case, I think we may need to do the quick if in ?
cc is there a chance to do another release of klog, so that we can use it in a patch release of k/k 1.29?
For 1.29, is a better fix than rushing a new klog release. But is this critical enough to ask the release team for an exception?
It only affects developers who bump up the verbosity to = 4.
So we can keep 1.29 as is, or do the quick fix in . I would suggest to do something about it, because it makes our log artifacts not so useful to detect real panics - a simple grep does not work anymore. do you think it makes sense to patch 1.29? Oh, yes, probably it is not critical enough, I keep forgetting about the = 4 level.
It's definitely not critical.

It's not even a real panic... it's just a log line that says "panic"
so better wait for the and then make the change? or add meanwhile?
I would wait, given that the cherry-pick is not justified