Support for sequential execution of middleware to be injected into incoming POST /tasks requests
Middleware classes to be executed can be specified, in fully qualified docstring notation, in the app configuration, in the desired order of execution, e.g.:
It is possible to specify one or more "fallback middlewares", in case the desired middleware fails; to achieve that, list nesting by one level is supported, such that each inner list is treated as a single "middleware group", from which at most one middleware is applied - the first one that does not raise a MiddlewareException; in the following example, proTES first attempts to apply MiddlewareClass1a; if it works, it will advance to the next item in the outer list, MiddlewareClass2 and try to apply that; however, if MiddlewareClass1a raises an error, proTES will first try to apply MiddlewareClass1b before progressing to MiddlewareClass2:
If all middlewares of any middleware group fail (including in groups of size 1, i.e, without list nesting), proTES will respond with a 500 response
Developers can implement their own middlewares by implementing the pro_tes.middleware.abstract_middleware.AbstractMiddlewareClass; of course, any middleware class provided via external packages needs to be made available to the application (e.g., by adding the corresponding package to requirements.txt and rebuilding the app and worker images)
Available middlewares for task distribution (random and distance-based) are now available in pro_tes.plugins.middlewares.task_distribution with all their dependencies
Task distribution middlewares are applied by default, as a single middleware group, with the distance-based distribution (pro_tes.plugins.middlewares.task_distribution.distance.TaskDistributionDistance) being attempted first, and with the random-based task-distribution (pro_tes.plugins.middlewares.task_distribution.random.TaskDistributionRandom) serving as a fallback; this behavior can be changed by modifying the middlewares app configuration section
Developers can optionally make use of the base class pro_tes.plugins.middlewares.task_distribution.base.TaskDistributionBaseClass for implementing other task distribution middlewares
Minor changes:
Replace legacy (Python <=3.7) Type hints for Lists, Dicts and Tuples with their lowercase counterparts across the entire application
Silence mypy complaints about missing type hints/stubs in external packages
Drastically simplify middleware handler and task distribution middleware code
Streamline POST /tasks controller code as a preparatory step for a major refactoring
Streamline logging
Temporarily disable unit tests in preparation for an effort to write consistent unit tests for the entire application
POST /tasks
requestsMiddlewareException
; in the following example, proTES first attempts to applyMiddlewareClass1a
; if it works, it will advance to the next item in the outer list,MiddlewareClass2
and try to apply that; however, ifMiddlewareClass1a
raises an error, proTES will first try to applyMiddlewareClass1b
before progressing toMiddlewareClass2
:500
responsepro_tes.middleware.abstract_middleware.AbstractMiddlewareClass
; of course, any middleware class provided via external packages needs to be made available to the application (e.g., by adding the corresponding package torequirements.txt
and rebuilding the app and worker images)pro_tes.plugins.middlewares.task_distribution
with all their dependenciespro_tes.plugins.middlewares.task_distribution.distance.TaskDistributionDistance
) being attempted first, and with the random-based task-distribution (pro_tes.plugins.middlewares.task_distribution.random.TaskDistributionRandom
) serving as a fallback; this behavior can be changed by modifying themiddlewares
app configuration sectionpro_tes.plugins.middlewares.task_distribution.base.TaskDistributionBaseClass
for implementing other task distribution middlewaresMinor changes:
List
s,Dict
s andTuple
s with their lowercase counterparts across the entire applicationmypy
complaints about missing type hints/stubs in external packagesPOST /tasks
controller code as a preparatory step for a major refactoringCloses #124