https://docs.all-hands.dev/ logo
Join Slack
Powered by
<@U07EZMGJFBJ> <@U08DZAR5JR3> re: polling behavior
# proj-agent-canvas
w
@straight-sundown-84319 @flaky-jordan-67349 re: polling behavior
CC @ancient-car-4311
a
Gonna ping @quick-window-91705 too for awareness šŸ˜„
w
I was originally thinking that Integrations Hub just handles credentials, and doesn't do any polling itself. And we'd use a cron automation to do the polling Someone (Tim? Rohit?) brought up a good point that this is a little hacky. It'd be nice if IntHub did the polling, and produced events. Then the automation is defined as an event-driven automation, and can be easily translated if the user wants to set up events in IntHub
For GitHub polling this would probably work well, since they expose an 
/events
endpoint, which we can easily consume
For Slack (and most other integrations) it's much harder, because we need the user to specify what to poll. We will hit rate limits fast if we poll every channel
I'm leaning towards MVP being that we rely on a cron automation to do the polling, rather than trying to support polling as a high-level IntHub abstraction
But I see the reasons not to
Curious to get your thoughts
q
^ yep we came to conclusion as well we already have a protocol for events consuming for cloud integration hub, we reuse the same protocols for local as that will be easiest to maintain going forward
Also every automation is a packaged tarball, so upgrading them in the future requires re-packaging and redeploying to every user (if we were to do a polling CRON); an integration hub helps separate that and makes future upgrades much easier
w
we already have a protocol for events consuming for cloud integration hub, we reuse the same protocols for local as that will be easiest to maintain going forward
this sounds like the opposite of what I'm saying?
I might be misunderstanding though
q
> It'd be nice if IntHub did the polling, and produced events ^ this is what we want a protocol has been establish for cloud integration hub <> automation (automation BE simply consumes events that match pre-determined conditions from the integration hub); the same would apply for local install. we'd have a local integration hub, but the method by which events are acquired is different (for cloud integration hub receives webhooks, for local it polls events)
w
Yeah my conclusion is the opposite šŸ™‚ that if we put the polling at that abstraction level, we run into serious problems
In particular: the user has no control over the polling. We're consuming their rate limits, and we don't know exactly what to poll for
q
Ah I see
w
Your solution is definitely more elegant/consistent. But I think from a practical standpoint it'll be much easier to have the user run the polling via a cron automation
q
Hmm yeah I see what you're saying From a UX standpoint its a bit annoying to setup a CRON as well, what if we exposed configurations for local integration hub?
w
How is it annoying to set up a cron? Don't I just tell the agent "do X every minute"?
what if we exposed configurations for local integration hub
we'd need per-app configurations šŸ˜ž really hard to maintain
q
Setting up an integration will require 1. creating credentials 2. setting up an mcp connection 3. asking agent to create a polling mechanism 4. asking agent to create an automation Its a lot of steps, out of these number 3 seems easiest for us to offload Per-app config is a problem too though @fierce-account-55183 can we configure polling criterion easily via JMESPath? Then uses can ask an agent to help build the polling configurations on integration hub side (which doesn't remove step 3 now that I think about, but helps with the abstraction)
w
1. asking agent to create a polling mechanism
2. asking agent to create an automation
These should be the same step!
q
AHH I see what you're saying now
w
From the user's perspective, they just click the "create slack responder" button that triggers a pre-built skill to create an automation that: ā€¢ runs every minute ā€¢ checks a slack channel ā€¢ stores the ID of the latest message in ~/.openhands/cronstate/slack.txt ā€¢ decides whether to start an agent
added benefit that this is also WAY less logic for us to implement and maintain
nod 2
q
Cool I think with this we can ship an MVP in one day basically, which sg w me. Seems most flexible too
w
šŸ™Œ glad we chatted through it!
šŸ’Æ 1
6 Views
Open in Slack
PreviousNext
Powered by