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
Hmmm, this is very odd that it's not working. My understanding was that the ServerErrorMiddleware will always be the outermost middleware due to these lines in FastAPI and Starlette. So the user middleware shouldn't matter? 🤔
We'll definitely take a look, thanks for providing a reproduction case.
basepi
changed the title
ordering of adding the ElasticAPM is no relevant and must be last middleware to be added
[Starlette] ordering of adding the ElasticAPM is no relevant and must be last middleware to be added
Nov 29, 2022
I can reproduce this issue. Just trying to figure out the best solution, because relying on users to get the middleware order correct isn't a viable solution IMO.
Because you're using a middleware which inherits from BaseHTTPMiddleware, our running transaction isn't propagated from our ElasticAPM middleware to the outer ServerErrorMiddleware because BaseHTTPMiddleware breaks contextvar propagation.
I am going to rely on a docs note for now, because I'm not sure how else to maintain our ability to collect all server errors while also allowing any order for BaseHTTPMiddleware.
Describe the bug:
Since elastic-apm>=6.13.0 we did not get transaction information anymore from our FastAPI application. It turned out that since then the order of adding multiple layers of middleware is relevant. If a middleware is added after
elasticapm.contrib.starlette.ElasticAPM
the transaction information is missing when the transaction is closed here https://github.com/elastic/apm-agent-python/blob/main/elasticapm/instrumentation/packages/asyncio/starlette.py#L52. Meaning the call here https://github.com/elastic/apm-agent-python/blob/main/elasticapm/base.py#L324 returns None in such a case.Reordering of adding the middleware layers does resolve the issue.
To Reproduce
run it with:
uvicorn app:app
4. check if transactions are send and complete in APM, which is not the case
Environment (please complete the following information)
Additional context
It seems that this happens since the change to the StarletteServerErrorMiddlewareInstrumentation done here https://github.com/elastic/apm-agent-python/pull/1674/files
requirements.txt
:Click to expand
The text was updated successfully, but these errors were encountered: