Skip to content

Middleware order is reversed for exit hooksΒ #505

@lroling8350

Description

@lroling8350

Middleware has hooks before task execution and after task execution. The order these hooks run in is dependent on the order they are placed on the broker. Lets take an example to illustrate this

broker.add_middlewares(
    MiddlwareA(),
    MiddlewareB() 
)

When a task executes the order of operations will be

# Initalization
A.startup -> B.startup
... operate
A.shutdown -> B.shutdown

# Sending
A.pre_send -> B.pre_send
...send 
A.post_send -> B.post_send

# Execution
A.pre_execute -> B.pre_execute
... execute
A.on_error -> B.on_error (only if there is an error)
A.post_execute -> B.post_execute
A.post_save -> B.post_save

Most middleware systems i've interacted with the post hooks happen in reverse order so you can think of going down the chain and back up. So it would be more like

A.startup -> B.startup
... operate
B.shutdown -> A.shutdown

# Sending
A.pre_send -> B.pre_send
...send 
B.post_send -> A.post_send

# Execution
A.pre_execute -> B.pre_execute
... execute
B.on_error -> A.on_error (only if there is an error)
B.post_execute -> A.post_execute
B.post_save -> A.post_save

This is helpful if you want middleware to piggy back on others. For example I am creating my own telemetry middleware and would like to appear first down the chain and last up the chain. This allows me to detect things like retries if the Simple or Smart retry middleware appears after.

Is this something that would be of interest to change or provide a configuration parameter to support?

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions