You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It appeared that the order of execution of these middleware modules in the success scenario was:
before_work: ONE
before_work: TWO
<worker module's perform>
after_processed_work: ONE
after_processed_work: TWO
and similar for after_failed_work callbacks in the worker's crash scenario.
Expected behaviour
I thought that after_*_work functions should be called in a reversed order so that middleware modules "wrap" each other like this:
before_work: ONE
before_work: TWO
<worker module's perform>
after_processed_work: TWO
after_processed_work: ONE
This way after_*_work callback of a middleware has a chance to cleanup any side-effects it introduced in before_work (e.g. I'm hacking on pipeline.assigns.worker_module and pipeline.assigns.job.args).
The text was updated successfully, but these errors were encountered:
At this point, it would be hard to change the existing behavior without breaking some existing code. We could probably consider a compile-time flag if there are some good use cases that can't work based on the current ordering logic.
Tested this in exq v0.15.0:
It appeared that the order of execution of these middleware modules in the success scenario was:
and similar for
after_failed_work
callbacks in the worker's crash scenario.Expected behaviour
I thought that
after_*_work
functions should be called in a reversed order so that middleware modules "wrap" each other like this:This way
after_*_work
callback of a middleware has a chance to cleanup any side-effects it introduced inbefore_work
(e.g. I'm hacking onpipeline.assigns.worker_module
andpipeline.assigns.job.args
).The text was updated successfully, but these errors were encountered: