From:
To:
Design the 36 hour cool-down service infrastructure.
The crucial Quality Control requirement the IMS must enforce is:
“Do not batch and seal a CCT roll into its packaging until a 36 hour cooling period has expired, due to the risk of condensation buildup”.
The enforcement mechanism we will adopt is to prevent release into the CCT Batching inbox until 36 hours after production.
The other angle to perceive this feature is to automate the following business logic:
“After the 36 hour cooling period has elapsed, place all IRR’d CCT rolls in the CCT batching Inbox”.
And taking this perspective circumvents the need to “enforce” a QC rule while still adhering to it, and adding the value of the behaviour automation.
Because this is an automation of business logic which adheres to a QC rule but doesn’t enforce it, we must ensure that the automation does not prevent circumvention of the QC rule, nor does its underlying service fail if it is circumvented.
The central infrastructure that is missing to facilitate this purpose is a Time-based Task Scheduler
The interface we need access to is to submit the following:
“At time perform task “
Having now built a bare-bone task-scheduler service which runs a python script once per minute, I need to structure a task registry to CRUD tasks the task-scheduler will run.
The frame will be constructed in the process-model. The first-pass implementation is
ScheduledTask(id):
- scheduled_for: datetime
- task_type: TaskType(id) - {name, …}
- deprecation: Deprecation
- arguments: json
- agent: Agent
- execution_status: ExecutionStatus
Having discussed my first design proposal with @DB, we have resolved to use HTTP as the RPC mechanism, so the tasks are defined as HTTP endpoints.
erDiagram
"tasks.endpoint_definitions" ||--o{ "tasks.scheduled_requests":""
"tasks.endpoint_responses" |o--|| "tasks.scheduled_requests":""
The other crucial aspect is to to design a TaskState enumeration as a function of the ScheduledRequest instance.
I also need to safely handle where executing a task causes an exception in the scheduled-task-executor itself.
I hand response statuses not 200 as part of the EndpointResponse, but in order to safely and robustly handle when an exception is raised, a super-structure is required. The way I am going to handle this is that the scheduled-task-executor will cancel the scheduled request and give a reason which includes an exception. Additionally, the full stack-track will be logged to file.
Now having all the essential aspects to schedule, execute, and record tasks, I want to design an API which is simple and safe, exposing what is needing to schedule tasks and query their progress.
The key to the API is that it provides a set of methods to carry out all operations facilitated by the library.
I think the only one missing is schedule_request.
The first step in task scheduling is registering an HTTP endpoint as schedulable. The vast majority of our endpoints are Django views, so a convenient API to register existing Django views is the simplest way. The ideal place to hook this registration in is as part of the urlpatters construction, as it is essentially the same operation. Maybe this can be built as a Django middleware.
This requires two aspects to function: 35.1
- A
schedulable_pathfunction which is a wrapper around thepathfunction, which is itself aURLPatternfactory which emits aSchedulableURLPatternwhich encodes the additional state needed to register the schedulable routes. register_schedulable_paths, a customdjango-admincommand which CRUDsEndpointDefinitions recorded in the database to match the state of those defined inurlpatterns.
Having now made the registration redundant, I need to create the tasks app to resolve requests dynamically from an api_router endpoint. 35.2
To avoid scope creep, the above is being skipped for the MVP.