requeue transient snapshot upload-result read races instead of failing - #393
requeue transient snapshot upload-result read races instead of failing#393benldrmn wants to merge 2 commits into
Conversation
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 0856e973d7
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
|
|
||
| if len(podList.Items) == 0 { | ||
| return nil, fmt.Errorf("no pods found for job %s", job.Name) | ||
| return nil, true, fmt.Errorf("no pods found for job %s", job.Name) |
There was a problem hiding this comment.
Avoid retrying permanently missing upload pods forever
When the case documented above actually happens and the completed Job's pod was GC'd after a node scale-down, this branch will never become readable: the Job is already complete, no new pod event will recreate the pod, and CompletionTime stays nil so TTL cleanup never runs. The controller will requeue every five seconds indefinitely and leave the RootfsSnapshot/Job stuck InProgress; add a bounded retry or fallback instead of treating every empty pod list as transient.
Useful? React with 👍 / 👎.
No description provided.