azure-functions-python-worker icon indicating copy to clipboard operation
azure-functions-python-worker copied to clipboard

Null Message Body Reprocessing Messages from Service Bus Subscription

Open TylrRssll opened this issue 1 year ago • 1 comments

Affects models V1 and V2 and the latest available library version.

Service Bus Subscription

Question

We are encountering an issue that Azure support has not been able to help with so hopefully we may obtain an answer here.

We have a simple azure function using the latest python library version that when reading specific messages from a service bus subscription the body of the message is returning as null. The messages in question have been re-sent to the service bus topic from the dead letter queue as the original invocation of the function failed after reading the message body but the failure reason is unrelated to the issue I am reporting.

When the message is re-sent from the DLQ of the subscription to the topic the azure function will fire, the first command executed is

message.get_body().decode("utf-8")

When executed the body returned is null, however when viewing the message in service bus explorer prior to the function reading the message the body contains valid JSON.

What we have established is that if the topic has large message support enabled (max message size 10MB rather than the default 1MB), if a message is resent from the DLQ to the subscription, the body when read in the azure function using the snippet above is null, if the topic does not have large message support enabled the message body is NOT null.

After significant investigation a colleague of mine has found that the message published directly to the topic using any means (programmatically or via the azure portal service bus explorer) has a message body type of AmqpMessageBodyType.DATA but when the same message is re-sent from the DLQ and subsequently read by the azure function the message body type is AmqpMessageBodyType.VALUE.

My suspicion is that the get_body() method does not work as expected when the message body type is AmqpMessageBodyType.VALUE and thus returns a NULL.

Lastly the azure support team that provides support for the service bus service will no longer provide support on the issue as they claim as the message body is visible in service bus explorer the issue must lie with the azure functions sdk.

TylrRssll avatar Jun 25 '24 15:06 TylrRssll

Hi @TylrRssll, thanks for opening this issue.

A couple follow-up questions to make sure I understand the situation --

The messages in question have been re-sent to the service bus topic

  • Is this issue only happening for messages that have been re-sent to the SB topic? The original invocation processed the message body correctly (ie. did not return null)?
  • Are you getting an error message from the get_body() method? What is get_body() returning? (ie. none or empty string)

if the topic does not have large message support enabled the message body is NOT null

  • This means that having large message support enabled results in the message body being null? This issue then only occurs when the topic has large message support enabled?
  • Does this include messages that have been re-sent as well? (messages that are re-sent are read correctly if large message support is disabled)
  • How large are the messages being sent?

the get_body() method does not work as expected when the message body type is AmqpMessageBodyType.VALUE

  • It looks like when the DATA type means that the message body is bytes, and the VALUE type means that the message body can be any type
  • Did you find that this message body type change happens only if large message support is enabled? Do you know if it also happened when large message support isn't enabled? (did this change also occur when the message body was read correctly?)
  • In the azure-functions SDK:
    • Only string, bytes or bytearray types are supported -- if not that, an error is thrown
    • If it's a string, we convert it to bytes
    • Return the body as bytes

I'm not sure why the message body type changes for resends, but seeing as the type did change, there might be a missed edge case somewhere.

hallvictoria avatar Jul 01 '24 16:07 hallvictoria

Thank you for the reply, answers to your questions are below:

Q: Is this issue only happening for messages that have been re-sent to the SB topic? The original invocation processed the message body correctly (ie. did not return null)?

A: The issue only happens for messages re-sent from the DLQ.

Q: Are you getting an error message from the get_body() method? What is get_body() returning? (ie. none or empty string) if the topic does not have large message support enabled the message body is NOT null

A: No error is encountered, the get_body() is returning null. And yes if large message support is not enabled then the message body is successfully returned.

Q: This means that having large message support enabled results in the message body being null? This issue then only occurs when the topic has large message support enabled?

A: Yes only occurs when large message support is enabled.

Q: Does this include messages that have been re-sent as well? (messages that are re-sent are read correctly if large message support is disabled)

A: When large message support is disabled then message can be re-read sucessfully.

Q: How large are the messages being sent?

A: For all messages all that we have had in the dead letter queue the JSON payload is correct and the size < 1KB

Q: Did you find that this message body type change happens only if large message support is enabled? Do you know if it also happened when large message support isn't enabled? (did this change also occur when the message body was read correctly?)

A: This message body type change only occurs for re-sent messages when large message support is enabled on the topic.

TylrRssll avatar Jul 11 '24 10:07 TylrRssll

Hi, apologies for the delay.

I tried to repro this scenario, and here is what I found: Message body is "test".

When large message support is enabled and the message is re-sent from the dead letter queue: Body: ""

When large message support is enabled and the message is re-sent from the queue: Body: "test"

When large message support is enabled and the message is sent normally: Body: "test"

When large message support is disabled and the message is sent in any form: Body: "test"

I did see that the body is not correct when large message support is enabled and the message is re-sent from the dead letter queue, but I didn't see it displayed as null. I saw it displayed as "", empty string. When the message body is empty, I see Body: "null", or null as a string. I never saw the message body displayed as null, not a string.

Are you seeing Body: null or Body: "" or something else?

hallvictoria avatar Jul 31 '24 21:07 hallvictoria

This issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 4 days. It will be closed if no further activity occurs within 3 days of this comment.