airflow icon indicating copy to clipboard operation
airflow copied to clipboard

Prevent transient error in case when Pod start_time parameter is None

Open Crowiant opened this issue 3 weeks ago • 2 comments

There is a chance of a transient error inside the Kubernetes provider when two identical pods are spawned but the pod.status.start_time parameter is not set yet. To prevent this situation, an additional check of creation_timestamp was added. It is a more convenient step to compare identical pods based on the time when etcd receives information about the pod rather than when the scheduler sends information to the kubelet.


^ Add meaningful description above Read the Pull Request Guidelines for more information. In case of fundamental code changes, an Airflow Improvement Proposal (AIP) is needed. In case of a new dependency, check compliance with the ASF 3rd Party License Policy. In case of backwards incompatible changes please leave a note in a newsfragment file, named {pr_number}.significant.rst or {issue_number}.significant.rst, in airflow-core/newsfragments.

Crowiant avatar Dec 05 '25 15:12 Crowiant

Hello @potiuk @shahar1 could you please review the PR? Thank you!

Crowiant avatar Dec 10 '25 10:12 Crowiant

Not sure why you are calling me - that's not my area of expertise. Generally what we prefer is when you are pinging to attract maintainer to review - ping "in general" "Hey can I get a review" - generally speaking when I answer to your ping now that "this is not my area of expertise" - this will significantly decrease your chances of getting help from some other maintainer, because they will see I was involved (and they will not even see that I responded "not my area of interest".

But .. you made your choice.

potiuk avatar Dec 10 '25 18:12 potiuk

Hello @potiuk , @shahar1 !

Thank you for the comments.

I tagged you because I saw that Jarek previously participated in Kubernetes provider PRs approvals, and Shahar approved my previous PR (#49899).

While I understand your point, please note that the auto-assigned reviewers haven't reviewed any PRs in the last 6 months. I tagged you because the standard process didn't seem to be working.

Since I mostly contribute to the Google provider, I assumed tagging active maintainers was the right move to unblock the PR. I wasn't trying to be disruptive, just trying to get the code reviewed. So I apologize if I didn't follow the specific protocol for Kubernetes provider. I'll keep this in mind for next time.

Crowiant avatar Dec 15 '25 17:12 Crowiant

While I understand your point, please note that the auto-assigned reviewers haven't reviewed any PRs in the last 6 months. I tagged you because the standard process didn't seem to be working.

I am not sure where you get that statistics from, but maybe try to ping those auto-assigned reviewers. You have not tried it yet and seems that they are best suited. Maybe they don't realise you wait for their review?

potiuk avatar Dec 16 '25 11:12 potiuk

Hello @potiuk ! Yes, my mistake, I checked manually and missed some of the PR´s reviewed by the code owners. I apologize for the false statement. Thank you for pointing it out. I will ping them in a separate comment.

Crowiant avatar Dec 16 '25 14:12 Crowiant

Hello @hussein-awala @jedcunningham could you please help with the review of the PR? Thank you!

Crowiant avatar Dec 16 '25 14:12 Crowiant