). So my question is about orchestration settings that will be released in the future. Is custom orchestration policies will be parameters of API requests to set state of task/flow? Or orchestration concepts and APIs will be seriously changed in the near future? How orchestration policies will be serialized/deserialized between server and agent’s engines?
). In this case I try to return response data about time as a
of failed State object that will be checked in custom retrying policy. Policy behaviour is simple in this case — check state data and return AwaitingRetry with some time instead of Failed state.
So far I got a response from the team that orchestration policies can be (for now) considered internal, since we have not yet put machinery in for user-customizable policiesThank you for fast response! It’s mean for me that I correctly understood concepts of orchestration. Orchestration policies more about task/flow lifecycle, but not about business logic of workflow. So retrying in some cases like above is more business logic than task behaviour. It’s more about flow/task source code than orchestration. Correct?
Without retrying policy i try to implement this behaviour in flow code. Awaiting task result, check state, pause until some time and retry task in loop.Orchestration policies are indeed customizable but we haven't exposed an endpoint to configure that yet. But if you are willing to configure that in your flow instead, this is something I could help with more.
Orchestration policies more about task/flow lifecycle, but not about business logic of workflow.You're spot on, your business logic should live within your tasks and flows, not within orchestration policies.
Run task and get result. If task failed then pause (sleep) until some moment and run task again.This sounds like the best and most natural way of approaching it
state, tasks tagged with an
tag will sleep based on some exponential backoff you've configured before being asked to re-enter a
state again. This capability hasn't been wired up because we wanted to understand how our users wanted to interact with them before deciding on a design! However in all likelihood, the way you'd add a custom policy is to configure them when you're setting up your Orion server. And because all Orchestration rule code runs on the server behind the API and not the agent machines, once you've done this all your tasks and flows will be governed by the additional logic. If you find more reasons to want to customize your Orchestration policies, please don't hesitate to let us know 😛refect-duck: