Open silas opened 2 years ago
FWIW this also affects the ValidationCache
extension. It must run the on_validation_start
hook after parsing is complete so that the execution_context.graphql_document
is available - but the execution_context
may have been replaced with the one for a subsequent request (so it may be None
, or perhaps worse, one for a different request).
My current workaround is to replace the in built validation cache with one that is not directly instantiated: https://gist.github.com/jthorniley/f73f4866b229fd0579ac7fea37051806
I've just noticed this behavior.
I expected on_request_start
to have exactly one corresponding on_request_end
It looks like instantiated extensions passed to Schema are racy.
Example of racy usage:
https://github.com/strawberry-graphql/strawberry/blob/d6137f02a85c8659aedebac9c9e813ff72f267fe/tests/schema/extensions/test_opentelemetry.py#L200-L202
For
OpenTelemetryExtension
a single instance of_span_holder
is going to be created and reused.https://github.com/strawberry-graphql/strawberry/blob/d6137f02a85c8659aedebac9c9e813ff72f267fe/strawberry/extensions/tracing/opentelemetry.py#L31
Beyond just
OpenTelemetryExtension
, the setting ofexecution_context
inExtensionsRunner
is racy:https://github.com/strawberry-graphql/strawberry/blob/d6137f02a85c8659aedebac9c9e813ff72f267fe/strawberry/extensions/runner.py#L33-L40
You can trivially show this using the following example:
Create
app.py
Then run the following:
In a new window make the following request:
And while that request is running, make the concurrent request:
If you look at the output of
app.py
you'll see the following:You'll notice there is no
on_request_end
for4478640672
and a double execution of4478932016
.Upvote & Fund