Bugzilla

Where is interruption documented, specifically? I see in that comment that a middleware can intercept or rewrite an Action, both of which can be accomplished by calling (or not calling) `next` and don't require a separate dispatch.

I will also note that our implementation of having a separate middleware dispatch is [not behavior that matches the JS Redux implementation](https://redux.js.org/understanding/history-and-design/middleware#attempt-6-na%C3%AFvely-applying-the-middleware), for whatever the prior art is worth in this case:

> [applyMiddleware] only exposes a subset of the store API to the middleware: dispatch(action) and getState().

The underlying behavior difference is documented in this snippet from the middleware dispatch comment:

```
     * This method is particular useful if a middleware wants to dispatch an additional [Action] and
     * wait until the [state] has been updated to further process it.
```

I am questioning whether we want two fundamentally different flows for the ways Actions pass through these components. It could be that this is useful and necessary for our existing infrastructure, but that a deeper investigation could allow us to streamline this area with no loss of functionality.

Where is interruption documented, specifically? I see in that comment that a middleware can intercept or rewrite an Action, both of which can be accomplished by calling (or not calling) `next` and don't require a separate dispatch.

I will also note that our implementation of having a separate middleware dispatch is [not behavior that matches the JS Redux implementation](https://redux.js.org/understanding/history-and-design/middleware#attempt-6-na%C3%AFvely-applying-the-middleware), for whatever the prior art is worth in this case:

> [applyMiddleware] only exposes a subset of the store API to the middleware: dispatch(action) and getState().

The underlying behavior difference in our middleware is documented in this snippet from the middleware dispatch comment:

```
     * This method is particular useful if a middleware wants to dispatch an additional [Action] and
     * wait until the [state] has been updated to further process it.
```

I am questioning whether we want two fundamentally different flows for the ways Actions pass through these components. 

1. Actions are processed by middleware as they are received by the Store.
vs
2.  Middleware have full control over the Action processing pipeline and can even hijack the Store processing by dispatching Actions repeatedly.

It could be that (2) is useful and necessary for our existing infrastructure, but I am hoping that a deeper investigation would allow us to streamline this area with no loss of functionality.