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
I'm trying using your library to receive notifications from a platform that only supports long-polling. I am rather new to Cometd but I did testing using the platform's example through Postman. It seems like the order of messages to set up that they are suggesting is /meta/handshake, /meta/subscribe, then /meta/connect, where the actual long-polling is held at the connect message until a notification is received.
However as I adapted your example to receive notifications from the platform, I can see the outgoing handshake message, followed by the incoming handshake message and finally the outgoing connect message where the long-polling is held. As the subscribe method is not
called until client is set up, I'm never able to receive any notification from the channel I'm interested in.
async def chat():
# connect to the server
async with Client(f'https://platform.com/notifications', extensions=[MyExtension]) as client:
await client.subscribe("/DecodedEventListener/trigger")
# listen for incoming messages
async for message in client:
print(message)
Hi @robertmrk
I'm trying using your library to receive notifications from a platform that only supports long-polling. I am rather new to Cometd but I did testing using the platform's example through Postman. It seems like the order of messages to set up that they are suggesting is /meta/handshake, /meta/subscribe, then /meta/connect, where the actual long-polling is held at the connect message until a notification is received.
However as I adapted your example to receive notifications from the platform, I can see the outgoing handshake message, followed by the incoming handshake message and finally the outgoing connect message where the long-polling is held. As the subscribe method is not
called until client is set up, I'm never able to receive any notification from the channel I'm interested in.
I am not sure if the order was defined in the protocol spec or whether there's something I've missed, but this is what I found in Salesforce's documentation (not the platform I'm referring to), where 'subscribe' happens before 'connect'.
https://developer.salesforce.com/docs/atlas.en-us.api_streaming.meta/api_streaming/using_streaming_api_client_connection.htm
Code:
Output:
The text was updated successfully, but these errors were encountered: