-
Notifications
You must be signed in to change notification settings - Fork 2.8k
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
Handler failed: Received invalid frame type: 49, expected: 0
on upgrading to azure-servicebus
7.12.3
#37547
Comments
Thank you for your feedback. Tagging and routing to the team member best able to assist. |
Hi @gareththackeray, I am not able to reproduce that error on my side. Would you be able to share some logs or steps to reproduce the problem. Simply calling receive_messages on async is not raising that error for me. debug logs with tracing enable will also help. If you look at the sample below setting up debug along with The sample I used: import os
import asyncio
from azure.servicebus.aio import ServiceBusClient
from azure.identity.aio import DefaultAzureCredential
FULLY_QUALIFIED_NAMESPACE = os.environ['SERVICEBUS_FULLY_QUALIFIED_NAMESPACE']
QUEUE_NAME = os.environ["SERVICEBUS_QUEUE_NAME"]
import logging
import sys
log_fmt = logging.Formatter("%(asctime)s | %(levelname)s | %(threadName)s | %(name)s | %(message)s")
logger = logging.getLogger("azure")
logger.setLevel(logging.DEBUG)
handler = logging.StreamHandler(stream=sys.stdout)
handler.setFormatter(log_fmt)
logger.addHandler(handler)
async def main():
credential = DefaultAzureCredential()
servicebus_client = ServiceBusClient(FULLY_QUALIFIED_NAMESPACE, credential)
async with servicebus_client:
receiver = servicebus_client.get_queue_receiver(queue_name=QUEUE_NAME)
async with receiver:
received_msgs = await receiver.receive_messages(max_message_count=20, max_wait_time=5)
logger.debug(f"Received {len(received_msgs)} messages")
for idx, msg in enumerate(received_msgs):
print(f"Id: {idx}")
await receiver.complete_message(msg)
asyncio.run(main()) |
Hi @gareththackeray. Thank you for opening this issue and giving us the opportunity to assist. To help our team better understand your issue and the details of your scenario please provide a response to the question asked above or the information requested above. This will help us more accurately address your issue. |
Hi @kashifkhan thanks for the response and sorry it took a while to respond. I set up logging as you specified, and passed
|
@gareththackeray will you be able to share some of the logs before this What Im trying to understand is that why this error is showing up before transfers take place. Are you able to share the data you are pulling in or sending ? Also are you by any chance using one instance of the async client with multiple coroutines ? The library is not coroutine safe so you would need a lock around it. Essentially Im looking for a way to repro on my side because Im not able to do so simply using receive. I also noticed your init stack trace was on the sender and not on receive, so curious. |
Hi @gareththackeray. Thank you for opening this issue and giving us the opportunity to assist. To help our team better understand your issue and the details of your scenario please provide a response to the question asked above or the information requested above. This will help us more accurately address your issue. |
Hi @gareththackeray - I think I've managed to repro this. I've noticed that depending on where you're retrieving your endpoint information, an HTTP port may be automatically appended. For example, I deployed my ServiceBus namespace with bicep, and the endpoint output is generated in the format: Previously the scheme and port were being discarded in the case of connection via AMQP. However with the recent patch that's no longer the case. This HTTP endpoint would function correctly if you attempt to connect using websockets. I think to resolve this, the SDK should be updated so that we don't attempt to establish an AMQP connection over a known HTTP port. In the meantime, if you think the port is same issue you encountered, you should be able to be unblocked by either stripping the http port from the endpoint, or connecting over websockets (requires extra dependency installation): |
That's fixed it - excellent deduction and thanks so much @annatisch. |
This has been addressed in the latest release of Service Bus |
Hi @gareththackeray. Thank you for opening this issue and giving us the opportunity to assist. We believe that this has been addressed. If you feel that further discussion is needed, please add a comment with the text "/unresolve" to remove the "issue-addressed" label and continue the conversation. |
Describe the bug
After upgrading, we received the error
Caught exception: ServiceBusError('Handler failed: Received invalid frame type: 49, expected: 0.')
repeatedly. Stack trace:To Reproduce
Steps to reproduce the behavior:
receive_messages
Expected behavior
Successfully receive messages.
The text was updated successfully, but these errors were encountered: