Skip to content

fix(orchestrator): make ttlSecondsAfterFinished optional to prevent GitOps reconciliation loops#418

Merged
openshift-merge-bot[bot] merged 3 commits into
redhat-developer:mainfrom
rm3l:fix/orchestrator-ttl-gitops-compat
May 29, 2026
Merged

fix(orchestrator): make ttlSecondsAfterFinished optional to prevent GitOps reconciliation loops#418
openshift-merge-bot[bot] merged 3 commits into
redhat-developer:mainfrom
rm3l:fix/orchestrator-ttl-gitops-compat

Conversation

@rm3l
Copy link
Copy Markdown
Member

@rm3l rm3l commented May 29, 2026

Description of the change

When the chart is managed by a continuous reconciler (e.g., ArgoCD), the ttlSecondsAfterFinished field on the create-sf-db Job causes an infinite reconciliation loop: the Job finishes, the TTL controller deletes it after 300s, ArgoCD detects drift and recreates it, causing the DB creation script to re-run endlessly.

This PR makes ttlSecondsAfterFinished conditional; it is only rendered when explicitly set to a positive value. Users who want auto-cleanup can explicitly set orchestrator.sonataflowPlatform.dbCreationJobTTLSecondsAfterFinished to a positive integer.

Which issue(s) does this PR fix or relate to

How to test changes / Special notes to the reviewer

Checklist

  • For each Chart updated, version bumped in the corresponding Chart.yaml according to Semantic Versioning.
  • For each Chart updated, variables are documented in the values.yaml and added to the corresponding README.md. The pre-commit utility can be used to generate the necessary content. Run pre-commit run --all-files to run the hooks and then push any resulting changes. The pre-commit Workflow will enforce this and warn you if needed.
  • JSON Schema template updated and re-generated the raw schema via the pre-commit hook.
  • Tests pass using the Chart Testing tool and the ct lint command.
  • If you updated the orchestrator-infra chart, make sure the versions of the Knative CRDs are aligned with the versions of the CRDs installed by the OpenShift Serverless operators declared in the values.yaml file. See Installing Knative Eventing and Knative Serving CRDs for more details.

…itOps reconciliation loops

When managed by ArgoCD or similar reconcilers, the TTL controller
deletes the finished Job, causing drift detection and an infinite
recreate-rerun cycle. Default to nil (omit the field) so the Job
stays inert after completion; users who want auto-cleanup can
explicitly set dbCreationJobTTLSecondsAfterFinished to a positive value.

Assisted-by: Claude
@rm3l rm3l requested a review from a team as a code owner May 29, 2026 15:15
@rhdh-qodo-merge
Copy link
Copy Markdown

rhdh-qodo-merge Bot commented May 29, 2026

Code Review by Qodo

🐞 Bugs (3) 📘 Rule violations (0)

Grey Divider


Action required

1. TTL schema rejects zero 🐞 Bug ≡ Correctness
Description
dbCreationJobTTLSecondsAfterFinished now has minimum: 1, so configurations that set it to 0
will fail Helm schema validation and block installs/upgrades. This is a backwards-incompatible
change because 0 is a common explicit “disable” value while the docs also suggest disabling by
leaving it empty/null.
Code

charts/backstage/values.schema.tmpl.json[R578-581]

Relevance

⭐⭐⭐ High

Breaking schema likely flagged; prior TTL allowed minimum 0; 0-disable pattern common.

PR-#407

ⓘ Recommendations generated based on similar findings in past PRs

Evidence
The schema template and generated schema both enforce minimum: 1 for this field while allowing
null, meaning 0 is explicitly invalid and will be rejected by Helm’s schema validation when
users supply it.

charts/backstage/values.schema.tmpl.json[578-582]
charts/backstage/values.schema.json[491-497]
charts/backstage/values.yaml[536-541]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
The JSON schema for `orchestrator.sonataflowPlatform.dbCreationJobTTLSecondsAfterFinished` enforces a minimum of 1, which makes `0` an invalid value and can break existing users who explicitly set `0` to disable TTL.

### Issue Context
The chart now recommends disabling TTL by leaving the value empty/null, but Helm CLI and existing values files may still set `0` to disable. Rejecting `0` is a breaking validation change.

### Fix Focus Areas
- charts/backstage/values.schema.tmpl.json[578-582]
- charts/backstage/values.schema.json[491-497]

### Suggested fix
- Change `minimum` from `1` to `0` (or remove `minimum` and use `minimum: 0`) so that `0` is accepted.
- Keep `null` allowed.
- Clarify in the title/README that `null`/empty or `0` disables TTL, and positive integers enable it.
- Re-generate the raw `values.schema.json` from the template (as your pre-commit hook already does).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools



Remediation recommended

2. BackoffLimit bound removed 🐞 Bug ☼ Reliability ⭐ New
Description
The Helm values JSON schema for orchestrator.sonataflowPlatform.dbCreationJobBackoffLimit no
longer enforces any maximum, so accidental large values will pass schema validation and can make the
create-db Job retry far more times than intended. This weakens guardrails for a value that is
rendered directly into the Kubernetes Job spec.backoffLimit.
Code

charts/backstage/values.schema.tmpl.json[R571-576]

Relevance

⭐⭐⭐ High

PR #407 accepted adding schema guardrails for dbCreationJobBackoffLimit (incl. optional upper
bound); removing max likely rejected.

PR-#407

ⓘ Recommendations generated based on similar findings in past PRs

Evidence
The schema definition for dbCreationJobBackoffLimit now contains only minimum: 0 with no
maximum, while the Job template consumes this value directly as spec.backoffLimit, so overly
large values won’t be caught early by schema validation.

charts/backstage/values.schema.tmpl.json[571-576]
charts/backstage/values.schema.json[484-489]
charts/backstage/templates/sonataflows.yaml[213-215]
PR-#407

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The JSON schema no longer caps `orchestrator.sonataflowPlatform.dbCreationJobBackoffLimit`, allowing unreasonably large retry counts to pass Helm schema validation.

## Issue Context
This value is rendered directly into the create-db Kubernetes Job `spec.backoffLimit`, so schema validation is the main guardrail against accidental misconfiguration.

## Fix Focus Areas
- charts/backstage/values.schema.tmpl.json[571-576]
- charts/backstage/values.schema.json[484-489]

## Suggested fix
- Restore a reasonable `maximum` (e.g., `10`) for `dbCreationJobBackoffLimit` in `values.schema.tmpl.json`.
- Re-generate `values.schema.json` using the repo’s schema generation workflow (pre-commit hook) so the raw schema stays in sync.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools



Advisory comments

3. TTL gating not numeric 🐞 Bug ☼ Reliability
Description
The Job template uses with (truthiness) to decide whether to render ttlSecondsAfterFinished,
rather than checking that the value is > 0. If schema validation is bypassed, a negative TTL could
be rendered into the manifest and be rejected by the Kubernetes API as an invalid Job spec.
Code

charts/backstage/templates/sonataflows.yaml[R91-93]

Relevance

⭐⭐ Medium

No precedent for gt 0 checks; team typically relies on schema bounds.

PR-#407

ⓘ Recommendations generated based on similar findings in past PRs

Evidence
The template’s conditional is based on whether the value is non-empty (with), not on whether it is
positive; minimum: 1 exists in the schema, but the template itself does not enforce positivity.

charts/backstage/templates/sonataflows.yaml[85-95]
charts/backstage/values.schema.tmpl.json[578-582]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
The template currently renders `ttlSecondsAfterFinished` for any non-empty value via `with`. That’s not the same as enforcing a positive integer, and if schema validation is skipped a negative value would be emitted.

### Issue Context
This is defense-in-depth: the schema already enforces `minimum: 1` by default, but render-time checks make the chart more robust in non-validating pipelines.

### Fix Focus Areas
- charts/backstage/templates/sonataflows.yaml[90-95]

### Suggested fix
Replace the `with` block with an explicit numeric check, e.g.:
```yaml
{{- $ttl := (default 0 .Values.orchestrator.sonataflowPlatform.dbCreationJobTTLSecondsAfterFinished | int) }}
{{- if gt $ttl 0 }}
 ttlSecondsAfterFinished: {{ $ttl }}
{{- end }}
```
This keeps the field omitted for `null`/unset and for `0`, and only renders it for positive integers.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


Grey Divider

Previous review results

Review updated until commit 091a9b0

Results up to commit 3121b12


🐞 Bugs (2) 📘 Rule violations (0) 📎 Requirement gaps (0)


Action required
1. TTL schema rejects zero 🐞 Bug ≡ Correctness
Description
dbCreationJobTTLSecondsAfterFinished now has minimum: 1, so configurations that set it to 0
will fail Helm schema validation and block installs/upgrades. This is a backwards-incompatible
change because 0 is a common explicit “disable” value while the docs also suggest disabling by
leaving it empty/null.
Code

charts/backstage/values.schema.tmpl.json[R578-581]

Relevance

⭐⭐⭐ High

Breaking schema likely flagged; prior TTL allowed minimum 0; 0-disable pattern common.

PR-#407

ⓘ Recommendations generated based on similar findings in past PRs

Evidence
The schema template and generated schema both enforce minimum: 1 for this field while allowing
null, meaning 0 is explicitly invalid and will be rejected by Helm’s schema validation when
users supply it.

charts/backstage/values.schema.tmpl.json[578-582]
charts/backstage/values.schema.json[491-497]
charts/backstage/values.yaml[536-541]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
The JSON schema for `orchestrator.sonataflowPlatform.dbCreationJobTTLSecondsAfterFinished` enforces a minimum of 1, which makes `0` an invalid value and can break existing users who explicitly set `0` to disable TTL.

### Issue Context
The chart now recommends disabling TTL by leaving the value empty/null, but Helm CLI and existing values files may still set `0` to disable. Rejecting `0` is a breaking validation change.

### Fix Focus Areas
- charts/backstage/values.schema.tmpl.json[578-582]
- charts/backstage/values.schema.json[491-497]

### Suggested fix
- Change `minimum` from `1` to `0` (or remove `minimum` and use `minimum: 0`) so that `0` is accepted.
- Keep `null` allowed.
- Clarify in the title/README that `null`/empty or `0` disables TTL, and positive integers enable it.
- Re-generate the raw `values.schema.json` from the template (as your pre-commit hook already does).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools



Advisory comments
2. TTL gating not numeric 🐞 Bug ☼ Reliability
Description
The Job template uses with (truthiness) to decide whether to render ttlSecondsAfterFinished,
rather than checking that the value is > 0. If schema validation is bypassed, a negative TTL could
be rendered into the manifest and be rejected by the Kubernetes API as an invalid Job spec.
Code

charts/backstage/templates/sonataflows.yaml[R91-93]

Relevance

⭐⭐ Medium

No precedent for gt 0 checks; team typically relies on schema bounds.

PR-#407

ⓘ Recommendations generated based on similar findings in past PRs

Evidence
The template’s conditional is based on whether the value is non-empty (with), not on whether it is
positive; minimum: 1 exists in the schema, but the template itself does not enforce positivity.

charts/backstage/templates/sonataflows.yaml[85-95]
charts/backstage/values.schema.tmpl.json[578-582]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
The template currently renders `ttlSecondsAfterFinished` for any non-empty value via `with`. That’s not the same as enforcing a positive integer, and if schema validation is skipped a negative value would be emitted.

### Issue Context
This is defense-in-depth: the schema already enforces `minimum: 1` by default, but render-time checks make the chart more robust in non-validating pipelines.

### Fix Focus Areas
- charts/backstage/templates/sonataflows.yaml[90-95]

### Suggested fix
Replace the `with` block with an explicit numeric check, e.g.:
```yaml
{{- $ttl := (default 0 .Values.orchestrator.sonataflowPlatform.dbCreationJobTTLSecondsAfterFinished | int) }}
{{- if gt $ttl 0 }}
 ttlSecondsAfterFinished: {{ $ttl }}
{{- end }}
```
This keeps the field omitted for `null`/unset and for `0`, and only renders it for positive integers.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


Qodo Logo

@rhdh-qodo-merge
Copy link
Copy Markdown

Review Summary by Qodo

Make ttlSecondsAfterFinished optional for GitOps compatibility

🐞 Bug fix

Grey Divider

Walkthroughs

Description
• Make ttlSecondsAfterFinished optional to prevent GitOps reconciliation loops
• Default changed from 300 to nil (field omitted from Job spec)
• Users can explicitly set positive value for auto-cleanup if needed
• Updated documentation and schema to reflect optional behavior
Diagram
flowchart LR
  A["Job with TTL=300"] -->|"Causes infinite loop"| B["TTL controller deletes Job"]
  B -->|"ArgoCD detects drift"| C["Job recreated, script re-runs"]
  C -->|"Loop continues"| A
  D["Job without TTL field"] -->|"Recommended default"| E["Job stays inert after completion"]
  F["Explicit TTL value set"] -->|"Optional cleanup"| G["Job auto-deleted after TTL"]

Loading

Grey Divider

File Changes

1. charts/backstage/Chart.yaml ⚙️ Configuration changes +1/-1

Bump chart version to 6.0.1

• Bumped chart version from 6.0.0 to 6.0.1 (patch version)

charts/backstage/Chart.yaml


2. charts/backstage/README.md 📝 Documentation +5/-5

Update documentation for TTL field optionality

• Updated version badge from 6.0.0 to 6.0.1
• Updated helm install command example to use version 6.0.1
• Enhanced documentation for dbCreationJobTTLSecondsAfterFinished to clarify it's optional and
 recommended for GitOps
• Improved descriptions for related database creation job parameters

charts/backstage/README.md


3. charts/backstage/templates/sonataflows.yaml 🐞 Bug fix +3/-1

Conditionally render ttlSecondsAfterFinished field

• Made ttlSecondsAfterFinished field conditional using Helm with block
• Field is now only rendered when explicitly set to a non-nil value
• Prevents Job from having TTL by default, avoiding GitOps reconciliation loops

charts/backstage/templates/sonataflows.yaml


View more (3)
4. charts/backstage/values.schema.json ⚙️ Configuration changes +6/-4

Update JSON schema for optional TTL field

• Changed dbCreationJobTTLSecondsAfterFinished type from integer to ["integer", "null"]
• Removed default value of 300
• Changed minimum from 0 to 1 (only positive values allowed when set)
• Updated title to indicate field is optional and recommended for GitOps/ArgoCD

charts/backstage/values.schema.json


5. charts/backstage/values.schema.tmpl.json ⚙️ Configuration changes +3/-4

Update schema template for optional TTL field

• Changed dbCreationJobTTLSecondsAfterFinished type from integer to ["integer", "null"]
• Removed default value of 300
• Changed minimum from 0 to 1
• Updated title to indicate field is optional and recommended for GitOps/ArgoCD

charts/backstage/values.schema.tmpl.json


6. charts/backstage/values.yaml ⚙️ Configuration changes +4/-4

Set TTL field default to nil and update comments

• Changed dbCreationJobTTLSecondsAfterFinished default from 300 to nil (empty value)
• Updated comment to indicate field is optional and recommended for GitOps/ArgoCD
• Enhanced descriptions for database creation job parameters to reference Sonataflow

charts/backstage/values.yaml


Grey Divider

Qodo Logo

@rhdh-qodo-merge rhdh-qodo-merge Bot added documentation Improvements or additions to documentation Bug fix labels May 29, 2026
rm3l added 2 commits May 29, 2026 17:21
Kubernetes does not enforce a maximum on backoffLimit.

Assisted-by: Claude
@sonarqubecloud
Copy link
Copy Markdown

@rm3l
Copy link
Copy Markdown
Member Author

rm3l commented May 29, 2026

/cc @Fortune-Ndlovu

Followup to #407

@openshift-ci openshift-ci Bot requested a review from Fortune-Ndlovu May 29, 2026 15:30
@Fortune-Ndlovu
Copy link
Copy Markdown
Member

/agentic_review

@rhdh-qodo-merge
Copy link
Copy Markdown

rhdh-qodo-merge Bot commented May 29, 2026

Code review by qodo was updated up to the latest commit 091a9b0

Copy link
Copy Markdown
Member

@Fortune-Ndlovu Fortune-Ndlovu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the quick follow-up, @rm3l

Comment thread charts/backstage/values.schema.tmpl.json
Comment thread charts/backstage/values.schema.tmpl.json
Copy link
Copy Markdown
Member

@Fortune-Ndlovu Fortune-Ndlovu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm

@openshift-ci openshift-ci Bot added the lgtm label May 29, 2026
@openshift-merge-bot openshift-merge-bot Bot merged commit 3c3b2e8 into redhat-developer:main May 29, 2026
6 checks passed
@rm3l rm3l deleted the fix/orchestrator-ttl-gitops-compat branch May 29, 2026 17:17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Bug fix documentation Improvements or additions to documentation lgtm

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants