feat(operator): pod management - #359
Conversation
![sentry[bot]](https://avatars.githubusercontent.com/in/12637?s=60&v=4){kind=small}
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 2 potential issues.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit bafc46f. Configure here.
| workload_namespace=_workload_namespace(), | ||
| prune_stale_configmaps, | ||
| core=core, | ||
| workload_namespace=workload_namespace, |
There was a problem hiding this comment.
Cleanup orphans stuck pods
Medium Severity
delete_owned_pods skips pods that already have a deletionTimestamp and never force-deletes or waits for termination. Pipeline pods have no owner references, so once cleanup finishes and the finalizer is removed, stuck terminating pods are orphaned with nothing left to reclaim them.
Reviewed by Cursor Bugbot for commit bafc46f. Configure here.
| else: | ||
| raise kopf.PermanentError(f"Cannot apply unsupported manifest kind {kind}.") | ||
| pod_set_results[workload_set] = set_result | ||
| generations_by_set[workload_set] = generations |
There was a problem hiding this comment.
Partial reconcile then permanent stop
Medium Severity
Workload-set validation runs inside the per-set reconcile loop after earlier sets may already have been mutated. A later PermanentError (for example canary base name over MAX_BASE_NAME_LENGTH) skips status updates and returns no retry timeout, so the daemon waits indefinitely with partial cluster changes and stale status.
Additional Locations (2)
Reviewed by Cursor Bugbot for commit bafc46f. Configure here.
a5d6943 to
4b42ad7
Compare
bafc46f to
3e4187d
Compare
| return {} | ||
| return {int(ordinal): generation for ordinal, generation in data.items()} |
There was a problem hiding this comment.
Bug: The _parse_generations function does not ensure that generation values are integers, which can lead to a TypeError during reconciliation if the CR status contains non-integer data.
Severity: MEDIUM
Suggested Fix
In the _parse_generations function, explicitly cast the generation value to an integer within the dictionary comprehension to enforce the dict[int, int] return type. The line should be changed to return {int(ordinal): int(generation) for ordinal, generation in data.items()}.
Prompt for AI Agent
Review the code at the location below. A potential bug has been identified by an AI
agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's
not valid.
Location: sentry_streams_k8s/sentry_streams_k8s/operator/reconcile.py#L169-L170
Potential issue: The function `_parse_generations` is annotated to return a `dict[int,
int]`, but it only converts the dictionary keys to integers, not the values. The
generation values are used as-is from the input data, which is read from the Kubernetes
Custom Resource status. If the status contains non-integer generation values (due to
manual edits, data corruption, or changes between operator versions), this function will
return a dictionary with non-integer values. This incorrect data type is then passed to
`_allocate_generation`, where a call to `max()` will raise a `TypeError` when comparing
a non-integer with an integer, causing the reconciliation process to fail.
1 participant
No description provided.