Is there a good way to (a) have the flow runner in process or (b) see log output from the subprocess?
[2020-04-30 20:35:05,397] INFO - agent | Found 1 flow run(s) to submit for execution. [2020-04-30 20:35:05,397] DEBUG - agent | Updating states for flow run f7912fd5-8ce3-4048-8cfe-965a15d46845 [2020-04-30 20:35:05,400] DEBUG - agent | Flow run f7912fd5-8ce3-4048-8cfe-965a15d46845 is in a Scheduled state, updating to Submitted [2020-04-30 20:35:05,505] INFO - agent | Deploying flow run f7912fd5-8ce3-4048-8cfe-965a15d46845 [2020-04-30 20:35:05,519] DEBUG - agent | Submitted flow run f7912fd5-8ce3-4048-8cfe-965a15d46845 to process PID 46552 [2020-04-30 20:35:05,608] DEBUG - agent | Completed flow run submission (id: f7912fd5-8ce3-4048-8cfe-965a15d46845) [2020-04-30 20:36:22,277] INFO - agent | Process PID 46552 returned non-zero exit code
by the Agent. After this, from what I can tell each flow handles the transition from
by means of the
, so each
is calling the
with its own flow run, right? So maybe the conditions below don’t matter? First is since the server is written using async, if we put the concurrency check in the
call, and an API call comes in with N flow runs that are trying to transition into a
state and there’s M concurrency slots where M < N, how can we guarantee only M flows will transition into the
state? Second, when we’re creating the “Run Queue” in the
, we’re specifically returning flow runs in the order of first scheduled. Related to the above, if we’re submitting flow runs to a
state, are we guaranteeing that state changes in the flow runs submitted in the
mutation are occurring in order? If there are 3 flow runs and only one concurrency slot, are we just guaranteeing that one of the flow runs in the payload will succeed? Or are we guaranteeing that the first flow run in the payload will succeed?
Laura Lorenz (she/her)