https://docs.all-hands.dev/ logo
Join Slack
Powered by
It's a bit hard for me to work with automations wh...
# proj-automation
a
It's a bit hard for me to work with automations when they go straight to archive - any chance we could implement this idea of a configurable delay for sandbox cleanup that @curved-angle-80449 started on: https://github.com/OpenHands/automation/pull/33
l
I think that's a bug that Ai and I fixed in the runtime API, but we still need to deploy, maybe tomorrow
a
So what is the intended behavior of automations then? Are we not archiving them?
l
Correct
🙌 1
q
Every automation run is intentionally archived today on completion (and we might want to make this behavior configurable) The aggressive archiving bug in runtimes would likely manifest as automation runs archiving prematurely, which is a separate problem
l
Oh really? I think at least that should be configurable. I’d like to be able to ask follow-up questions on an automation. I didn’t think I was seeing them archived when I ran in agent canvas…
q
Agent canvas doesn't use sandbox isolation so conversations are alive by default! and yes would love to get that PR in @curved-angle-80449
c
I am pretty swamped @average-processor-75195 -- if you want to take that PR forward, please do.
a
Hey @quick-window-91705 — following up on PR #33 (configurable sandbox cleanup delay). You mentioned wanting to get that in, I had an agent port it over, resolved the merge conflicts, and the test suite passes (684/684). Full details in the comment on #33. Linear: APP-2287. Can you take it from here? 🙏
q
I'm starting to wonder whether we even need to perform sandbox archiving from the automation service As of right now runtime api already handles sandbox pausing/archival based on inactivity, which should be enough and we can avoid maintaining duplicate logic in the automation service
TLDR separate concerns • automation handles automation run status • runtime api handles sandbox status
a
(Yea, I never understood the motivation for archiving automation jobs)
q
We do end up consuming more resources as a consequence of adopting runtime api based cleanups only A middle ground is to make the sandbox cleanup policy configurable per automation (clean up sandbox immediately vs eventually) based on the use case
Hmm so turns out we've always had a configurable param on automations 
keep_alive
Setting that to 
true
will defer sandbox cleanup to the runtime api (based on user inactivity) So I think that should suffice. Maybe switching that boolean to a more descriptive enum should be enough
a
This worked, I was able to use the 
keep_alive
settings to get my enterprise Openhands automation jobs to not archive right away, i will start a separate thread in self-hosted about how to offer this configuration for enterprise admins.
q
Cool! I think there is a bug where the keep alive setting is configurable on a per run basis rather than on a per automation basis, which I'm fixing now github.com/OpenHands/automation/pull/209
a
Yea, i saw that bug and my agent did a database hotfix for that 😬
q
Uh oh, in prod?
Mind pinging on-call channel about it, with details on what migration was run
a
No, in my enterprise instance that I keep for myself
q
Ah cool 😮‍💨
a
Screenshot 2026-06-24 at 3.09.06 PM.png
🙌 1
2 Views
Open in Slack
PreviousNext
Powered by