Nested error middleware does not work correctly #277
Conversation
|
I've found the issue. When we get an array of middleware, we create a The real problem is the |
|
So glad to have found this issue. I've just spent the last 2 hours trying to figure out why my error middleware isn't being executed. |
|
@nesl247 You can do as I did in the summary, and split each out into its own spec; that works perfectly. I'll get the proposed |
|
I'm doing it as mentioned until the bugfix is in place. Thanks so much. Glad it wasn't me that was the problem here. |
When we create a middleware pipeline and denote it as being error middleware, the pipeline itself must have the error middleware signature. Additionally, the middleware piped into that error pipeline must each have the error middleware signature.
This patch implements an `ErrorMiddlewarePipe`. Unfortunately, `MiddlewarePipe` implements `MiddlewareInterface`, which makes it impossible to extend it and re-purpose it as error middleware. As such, this implementation wraps the `MiddlewarePipe` instance, and consumes its internal pipeline in order to dispatch a pipeline of error middleware.
This adds a test case for the ErrorMiddlewarePipe to verify that it: - aggregates a middleware pipe instance - dispatches the middleware composed in the middleware pipe instance - but only those that are error middleware
Currently, the `Zend\Stratigility\Next` implementation requires that the request and response passed to it are the Stratigility-specific decorators. As such, the `ErrorMiddlewarePipe` is required to decorate the incoming request and response. I chose to use reflection here so as not to duplicate logic; ideally, we can remove that requirement from the Stratigility library in the future.
Added CHANGELOG for #277
Added CHANGELOG for #277
|
On testing this in a real-world application, I'm finding it's still not working. Essentially, even though error middleware is being created, when |
|
#278 resolved the issue I was seeing, and I can report that those changes definitely allow middleware pipelines representing error middleware to work! New RC coming tomorrow! |
Given the following middleware specification:
[ 'middleware' => [ Unauthorized::class, Unauthenticated::class, ], 'error' => true, 'priority' => -10000, ]Neither middleware listed triggers. Each will trigger, however, if you do them separately, not as part of a list:
[ 'middleware' => Unauthorized::class, 'error' => true, 'priority' => -10000, ], [ 'middleware' => Unauthenticated::class, 'error' => true, 'priority' => -10000, ],The error is because the
MarshalMiddlewareTraitis not retaining thecomposes aerrorflag when marshaling lazy middleware services.MiddlewarePipeinstance when creating an error middleware pipeline, but that class does not implement the error middleware signature.This patch creates a
Zend\Expressive\ErrorMiddlewarePipeimplementation that consumes aMiddlewarePipeinstance while implementing the error middleware signature.MarshalMiddlewareTraitis updated to pass the generatedMiddlewarePipeinstance toErrorMiddlewarePipewhen generating an error pipeline.