hey - what's the best way to diagnose why an agent might not accept a flow? I have a scheduled run of a flow tagged with my local machine name, and I'm running an agent with the label. Is there any debug logging for the agent to show what flows it's considering? (I should mention I don't think this is related to the agents, as the UI says it's querying)

Hi @Matt Wong-Kemp - running the agent with

--verbose

should give you some info as the agent starts up, such as what labels it's running with and which endpoint it's querying.

Note: the backend does the filtering of what work should be released to an agent, so you won’t see any logs of any agent deciding not to run something

ok, so my agent ID is

Agent ID: 1d83b054-081a-437f-873b-dafd8a650ff4:LocalAgent:agent:ad622f995598:azure-flow-storage:gcs-flow-storage:github-flow-storage:s3-flow-storage

and my flow run is

8d6886e8-7530-4b64-ade4-e6f38dd442b2

- any idea why these two aren't matching?

Those are separate entities so it makes sense those would be different; what labels is your agent running with and what labels are on your flow?

I understand they're different - however both have the label

ad622f995598

applied

Hm yes, that sounds like your agent should be picking up your flow, if they both have the

ad622f995598

label

already done that once to turn on

verbose

- will try again

That's the next area of investigation, it's going to try to match your system time

I'm running in a docker container and some esoteric feature of the windows docker daemon is that the clock doesn't move on if your machine goes to sleep, so my container was querying for around 5pm UTC 🙂

ooooh, that might do it, are you able to restart the container?

it only fixes it if you restart the daemon, which worked (did however give me a different set of labels to match)

There should be no limits on the number of flows, since each flow is spun up as a separate process. Tasks on the local executor are limited to 1 in parallel in each flow though.

ok, thanks