How do I include setup/cleanup in operation state without breaking JobDispatcher/CountStrategy

[1nf0rmagician]

Problem In our application, OperationState is currently derived only from production jobs attached to OperationData.Jobs. Setups and cleanups are ignored. This leads to two issues:

1. If a manual cleanup is active, the order can show “successfully interrupted,” but the cleanup still blocks the next order.
2. Operators see tasks that don’t belong to the current order, which is confusing.

Attempting to “fix” this by changing the CountStrategy (e.g., returning false from CanReachAmount/AmountReached while setups/cleanups exist via JobManagement) causes the JobDispatcher to push more articles and can lead to state transitions like AmountReached → Interrupting, effectively breaking OrderManagement until a restart.

Question: How can we account for setup/cleanup phases when determining and presenting OperationState, without interfering with JobDispatcher/CountStrategy and the core job flow?

[1nf0rmagician]

Answering my own questions after some discussions now:

Some design decisions that reflect in the codebase

• Setups/Clean-ups are intentionally decoupled from production (jobs), see Setup Provider Module.
• Clean-ups are evaluated late for accuracy, limiting the general predictability, whether and how a clean-up is executed.
• The scheduler is the only component starting jobs and deciding which are schedulable (https://github.com/PHOENIXCONTACT/MORYX-Framework/blob/future/docs/articles/module-process-engine/JobManagement.md).
• The Order Management exposes begin/report restriction hooks wired by OperationBeginRequest/OperationReportRequest so adapters can add restrictions
• These restrictions are also renders by the Web UI them via the BeginContext GET /api/moryx/orders/{guid}/begin.
• Implementations of the IOperationDispatcher are another way of modifying the behaviour of starting operations. It acts a layer above the scheduler and could be used to control the behaviour of dispatching the operations in the first place.

Three options to modify behaviour safely

Scheduler option (recommended for flow control):

Method: Gate production jobs while clean-up is active; Implement a scheduler that refuses to start new production jobs while any clean-up is pending/active.
This modifies which jobs are scheduled, without changing order/operation behaviour.
Where: Implement SchedulableJobs in your scheduler (see).
What to check: Scan active jobs and detect clean-ups.

Lightweight UI clarity:

add BeginRestrictions via OrderManagementFacade Use the facade’s restriction events to surface “blocked by cleanup” to the operator. This is lighter weight than changing the OperationDispatcher and is rendered by the web UI automatically.
Hook into OperationBeginRequest on the facade (src/Moryx.Orders.Management/Facade/OrderManagementFacade.cs). Your adapter listens to OperationBeginRequest and adds a BeginRestriction (src/Moryx.Orders/Restrictions/BeginRestriction.cs) when cleanup is active.
The web UI retrieves BeginContext via GET /api/moryx/orders/{guid}/begin (src/Moryx.Orders.Web/src/app/api/fn/order-management/get-begin-context.ts) and displays restriction messages.
This makes the reason for blocking visible to users without changing scheduling, job counters, or operation behaviour.

Improving operator clarity with notifications

Dispatcher-level notification: If you already customize the OperationDispatcher, you can set a persistent notification on the operation while the clean-up is running (e.g., in JobStateChanged). This clarifies why the next order won’t start.

Resource-level notification: Use resource notifications to emit warnings while a clean-up is ongoing; clear them when done. If the provided visual instructions I assume your resource is displaying does not draw enough attention or is not visible from all areas in the machine, you can provide an additional notification for a more prominent feedback.

Summary

Control flow: Gate new production jobs in the scheduler (keeps job start decisions clean and separate from orders/operations).
UI clarity: Add lightweight BeginRestrictions via the OrderManagementFacade so the web UI shows blocking reasons; optionally add dispatcher- or resource-level notifications for better operator feedback.
Avoid modifying the CountStrategy to account for setup/cleanup. Use the designed extension points (scheduler, facade restrictions, dispatcher notifications) to keep the system stable.