-
-
Notifications
You must be signed in to change notification settings - Fork 511
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
Add the option in ChannelsConsumer to confirm topic subscription #2799
Comments
|
@DoctorJohn what do you think? 😊 |
|
Interesting. Yielding @strawberry.type
class FooSubscription:
@strawberry.subscription
@staticmethod
async def foo_subscription(info: Info) -> AsyncGenerator[FooType | None, None]:
gen = await info.context.ws.channel_listen("foo_type", groups=["a"])
yield None
async for message in gen:
yield FooType(message["payload"])However, this would still be a breaking change since @strawberry.type
class FooSubscription:
@strawberry.subscription
@staticmethod
async def foo_subscription(info: Info) -> AsyncGenerator[FooType | None, None]:
- async for message in info.context.ws.channel_listen("foo_type", groups=["a"]):
+ async for message in await info.context.ws.channel_listen("foo_type", groups=["a"]):
yield FooType(message["payload"]) |
|
Thanks for investigating possible solutions. Would an idea be to have a separate method that returns the awaitable AsyncGenerator but is used by the original channel_listen method? I'd agree that having the option of returning an awaitable AsyncGenerator instead yielding None as the first message is the more expected behavior. |
|
Should I create a pull request based on the following interface or do have you already coded something up? class ChannelsConsumer(AsyncConsumer):
async def channel_listen(...) -> AsyncGenerator[Any, None]:
return await self.base_channel_listen(...)
async def base_channel_listen(...) -> Awaitable[AsyncGenerator[Any, None]]:
... |
|
Personally I would go with the breaking change of having only one method and changing the signature. But @patrick91 might prefer the backwards compatible change of introducing a separate method.
I have a quick proof of concept without a test. So feel free to create a PR, I'll happily review it! |
|
I think we can afford a breaking change for this 😊 |
|
I created two approaches for handling channel_listen. One naive approach and one that uses a context manager to avoid missing cleanup. |
In order to inform the subscriber (GraphQL client) that the GQL subscription has been activated, it would be useful to return a null message. In order to avoid a race condition, it would be useful to configure
ChannelsConsumer.channel_listento return None as soon as the subscription on the channels layer has been activated.Feature Request Type
Description
In
ChannelsConsumer.channel_listen, I would like to add the option of yielding None after thechannel_layer.group_addloop:This would allow the subscriber to be written like this:
The commented out
yield Noneis a workaround but confirms the subscription before the topic has been subscribed to. This is noticeable in tests when testing the Channels communication via REDIS.Upvote & Fund
The text was updated successfully, but these errors were encountered: