feat(replicated): OHE-3231 expose the automation conversation archive delay as a ConfigOption

[hieptl]

Description

Exposes the automation service's new AUTOMATION_SANDBOX_CLEANUP_DELAY_SECONDS setting to self-hosted installs through the Replicated installer.

Automation-generated conversations are archived the instant a run finishes, because the automation service deletes the run's sandbox right away. A conversation whose sandbox is gone is read-only and cannot be resumed, so a run that failed or did something unexpected cannot be inspected. The service now supports a delay: above 0, the finished run's sandbox is paused instead of deleted, and its watchdog deletes it once the delay has passed, keeping the conversation resumable meanwhile. The delay has to be configurable at install time, and the KOTS config exposed no automation tunables at all.

Two Replicated manifests change; no chart files are touched:

• replicated/config.yaml — new item automations_sandbox_cleanup_delay_seconds, titled "Conversation Archive Delay (seconds)", in the existing automations_configuration group. type: text, default: "0", regex ^(0|[1-9][0-9]*)$ with a non-negative-integer message, and when: automations_enabled, so it only appears for installs that run automations. The help text states that the delay is measured from run completion, that the sandbox is paused in the meantime, and that values above the sandbox Deletion Time have no further effect.
• replicated/openhands.yaml — in the automations_enabled optionalValues block (recursiveMerge: true), maps the item into automation.env.AUTOMATION_SANDBOX_CLEANUP_DELAY_SECONDS, quoted so the chart receives a string.

The value reaches the pods through the plumbing that already exists: the umbrella chart's automation.env map and the automation subchart's deduplicating env wrapper, which renders arbitrary AUTOMATION_* variables into both the automation and events deployments. This is the same route the SaaS deployment already uses for its AUTOMATION_* settings.

Linear: OHE-3231 (part of OHE-2833)

Helm Chart Checklist

• I have tested the chart upgrade path from the previous version — no chart templates or values change, so the upgrade path is unaffected. Verified that helm template with automation.enabled=true and the value set renders AUTOMATION_SANDBOX_CLEANUP_DELAY_SECONDS into the automation deployment, and that helm unittest still passes for the umbrella chart (154 tests) and the automation subchart (14 tests).
• I have verified backwards compatibility with existing values.yaml configurations — no values.yaml key is added or renamed. The new config item uses default: "0", which is the automation service's current immediate-archive behaviour, so an existing install upgrades to identical behaviour until an operator changes the field.
• I have updated the chart's README.md if there are any breaking changes or new required values — there is neither a breaking change nor a new required value, so no README change is needed.

Additional Notes

• Ship order. This needs the automation service release that reads the variable to be deployed first, or in the same release; the corresponding automation.image.tag bump should land with or before this.
• Not a secret. The item is a plain text field, so secretsChecksum and the check-secret-checksum workflow are unaffected. values.schema.json has no automation section, so no schema change either.
• Semantics worth knowing when setting it. The delay is measured from run completion, not last activity, so opening and resuming a conversation does not extend it. If an operator sets a delay longer than the sandbox Deletion Time, the runtime's own reaper deletes the paused sandbox first; the service's later delete then finds nothing and logs it harmlessly. The help text covers both points.

[tofarr]

🍰

[openhands-release-bot]

🚀 Released in openhands/0.70.0.