feat: route events to an existing conversation via a derived conversation id Tested here: github.com/OpenHands/automation/issues/413 @calm-artist-7206 @quick-window-91705 thanks for the comments. I just tested in a local setting (via VM). @quick-window-91705 Did you have the chance to compare with your proposal? I'm happy to change the code accordingly. PS: still working out some nit

I had the agent post its breakdown, its super chunky apologies github.com/OpenHands/automation/pull/385#… TLDR though I think the biggest issue I have is that events are automatically sent into a running agent conversation I feel the automation script should control what to do with new incoming events and should not assume that the agent should receive it immediately And we require a running sandbox for session reuse to work, and we need the ability to resume the sandbox

Is it possible that the agent had a old commit? Because I think the machinery for the resume sandboxes is already in place > Events are automatically sent into a running conversation is opt-in. destination defaults to

dispatch_run

, so no existing automation changes behavior unless its trigger asks for it. > The script should control what to do with new events The cheapest way to fix that is:

SendMessageRequest.run

already defaults to False; the PR just hardcodes True. We can expose that as a trigger field. So the big missing point is cold-start / dead-sandbox case. But I think this is a big change or?

gotcha, seems reasonable to begin with then and sandbox lifecycle management can be a next step also have we accounted for this race condition where in a multi-pod env we can get multiple events in a quick burst and can cause duplicate runs

first event
→ create PENDING AutomationRun(subject_key=...)

second event arrives before first run has started
→ no started run found
→ create another AutomationRun(subject_key=...)

e.g scenario where two people trigger slack resolver back to back - i think we're already using the DB as a queue for incoming events might need to poll off it

Ah ok good point. I updaed the PR with this case which could effectively happens 🙂 Ready for another pass

left some more comments

answered 🙂

Thanks! Overall lgtm Left a comment here for a possible simplification opportunity: github.com/OpenHands/automation/pull/385/changes#…

The simplification should be in place ;) github is a little bit weird 🫣

sry some more comments 😅 im trying to err on the side of using configurable jmes path expressions wherever possible to keep the automation service as configurable as possible

No worries 🙂 next round ready😉