-
-
Notifications
You must be signed in to change notification settings - Fork 536
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unify single-response-requests with streaming requests on graphql-transport-ws
#1792
Conversation
test overlapped single result queries
Single result operations are now executed on a task. They can be cancelled like regular streamed operations. They can be overlapped like regular streamed operations. They don't have an associated generator, merely a task.
Codecov Report
@@ Coverage Diff @@
## main #1792 +/- ##
==========================================
+ Coverage 98.11% 98.15% +0.04%
==========================================
Files 139 139
Lines 5250 5260 +10
Branches 957 958 +1
==========================================
+ Hits 5151 5163 +12
+ Misses 53 52 -1
+ Partials 46 45 -1 |
graphql-transport-ws
graphql-transport-ws
Thanks for adding the Here's a preview of the changelog: This release fixes a number of problems with single-result-operations over
Here's the preview release card for twitter: Here's the tweet text:
|
strawberry/subscriptions/protocols/graphql_transport_ws/handlers.py
Outdated
Show resolved
Hide resolved
@@ -285,6 +285,55 @@ async def test_duplicated_operation_ids(aiohttp_client): | |||
assert data.extra == "Subscriber for sub1 already exists" | |||
|
|||
|
|||
async def test_reused_operation_ids(aiohttp_client): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As these are fairly complicated tests, could you add some docstrings describing what functionality is being tested
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good Idea.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added docstrings.
It is a bit annoying that we have three identical sets of tests, testing internal functionality, that is in theory quite independent of the integration in use. Would it make sense to separate "integration" tests from unit tests?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
cc @patrick91, I think we were discussing ideas for doing this last week
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@kristjanvalur totally, I've opened up an issue for this: #1809
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this looks great! thanks so much and sorry for the late review!
if operation_type == OperationType.SUBSCRIPTION: | ||
result_source = await self.schema.subscribe( | ||
query=message.payload.query, | ||
variable_values=message.payload.variables, | ||
operation_name=message.payload.operationName, | ||
context_value=context, | ||
root_value=root_value, | ||
) | ||
else: | ||
# create AsyncGenerator returning a single result | ||
async def get_result_source(): | ||
yield await self.schema.execute( | ||
query=message.payload.query, | ||
variable_values=message.payload.variables, | ||
context_value=context, | ||
root_value=root_value, | ||
operation_name=message.payload.operationName, | ||
) | ||
|
||
result_source = get_result_source() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
maybe in a future PR we can move this to a classmethod to clean this method 😊
(replaces closed #1739)
Various problems with single-response-requests existed as a result of their having a separate control
path from streaming requests. Single-response-requests are really just special cases of streaming requests
that deliver at most one
Next
message and need to behave as such.Description
single-response-request are now handled as tasks and can be overlapped with other requests
on the same connection, can be cancelled, and share the same unique requests ID namespace.
Types of Changes
Issues Fixed or Closed by This PR
complete
for a single request operation results in a disconnect. #1731Checklist