I understand that the middlewares are injected in-between and surrounded by the preceding ditto. At the course of each, we can invoke a call to next() and pass the baton to the succeeding, inwards ware. By that logic, the order might affect the behavior of the application. However, I can't see how the order might cause the chain to be broken (unless an exception occurs or a developer fails to invoke next()).

I noticed that the following order (vanilla weather project) does execute both middlewares.

app.Use(async (context, next) => throw new Exception());
app.UseEndpoints(endpoints => endpoints.MapControllers());

When I switch the order, as below, only UseEndPoints(...) is executed while Use(...) never happens (according to a bunch of breakpoints not hit and even an exception not being thrown).

app.UseEndpoints(endpoints => endpoints.MapControllers());
app.Use(async (context, next) => throw new Exception());

I have found some info relating to web sockets saying something about an error if the pipeline has run out. However, this doesn't produce the mentioned error and doesn't really invokes web sockets in my vanilla project. So I sense I'm missing something else.

...you must keep the middleware pipeline running for the duration of the connection. If you attempt to send or receive a WebSocket message after the middleware pipeline ends, you may get an exception...

CodePudding user response：

The reason is mentioned in your question: "a developer fails to invoke next()", although in this case it’s not a failure as such, as that middleware is essentially the end of the pipeline, if it finds an action to execute.

See the source.