Handling messages with empty string as session id inconsistency

[akhudairymicrosoft]

• Package Name: azure/service-bus
• Package Version: 7.9.4
• Operating system: windows
• nodejs
  • version: v20.11.0
• browser
  • name/version:
• [x ] typescript
  • version: 5.6.3
• Is the bug related to documentation in
  • README.md
  • source code documentation
  • SDK API docs on https://learn.microsoft.com

Describe the bug
Currently there are inconsistencies in behaviors when sending a message with empty string as session id. While when using null as session id the behavior looks right for all.

Logically we expect if the subscription has session enabled, that sending a message with null session id or empty string should have same behavior, and that is for message to go to the DLQ. But that is not what is happening.

The C# library seem to have the correct behavior. As it treats both null and empty string as same on send. At same time if there was already messages with empty string in the active queue, it will allow the client app to process them.

To Reproduce
Steps to reproduce the behavior:

• Create a topic, and subscription with sessions enabled

• Send message with empty string as session id using js library (Result: message goes to the active queue)

• Send message with empty string as session id using Rest API (Result: message goes to the active queue)

• Send message with empty string as session id using C# library (Result: message goes to the DLQ)

• Try reading the message from the subscription using JS library by passing empty string as session id sbClient.acceptSession(queueName,"sub3" , ""). (Result: The app will NOT be able to read the message.)

• Try reading the message from the subscription using C# library by passing empty string as session id sbClient.acceptSession(queueName,"sub3" , ""). (Result: The code will SUCCESSFULLY read the message.)

Expected behavior
Expect the JS library to be consistent with C# behavior on send and receive of messages with empty string as session id. That is:

• On send message with empty string session id or with null to a session enabled subscription, then the message should go to DLQ
• If there was a message with empty string as session id in the active queue in the subscription, then the client should be able to process it using acceptSession or acceptNextSession

Screenshots
If applicable, add screenshots to help explain your problem.

Additional context
This is related to a customer support case. Please contact me over Teams for any details.

[github-actions]

Thanks for the feedback! We are routing this to the appropriate team for follow-up. cc @EldertGrootenboer.

[jeremymeng]

@akhudairymicrosoft thank you for logging the issue! We will take a look.

[jeremymeng]

• Try reading the message from the subscription using JS library by passing empty string as session id sbClient.acceptSession(queueName,"sub3" , ""). (Result: The app will NOT be able to read the message.)
• Try reading the message from the subscription using JS library by passing empty string as session id sbClient.acceptSession(queueName,"sub3" , ""). (Result: The code will SUCCESSFULLY read the message.)

@akhudairymicrosoft did you mean to have "C#" in the last bullet point?

[jeremymeng]

@akhudairymicrosoft empty string is actually a valid session id. .NET SDK is being outlier here by treating it the same as null. We will not align with .NET SDK's behavior.

The issue of being unable to accept a session with id of "" is actually a bug/regression in JS SDK. I opened PR #31736 to address it.

[akhudairymicrosoft]

Hi @jeremymeng

Thank you for accepting this one.

I fixed the steps to reproduce.

Thanks for opening the PR regarding ability to receive.

I understand your reply here and the cause of it. I think if it was my business decision I would go for treating empty string exactly same as null and just force it to go to DLQ.

Just kindly note one thing. The C# while it can receive the messages. It has a weird behavior. When the message is received to process if you check the session id, you will see it is null and not an empty string. So all in all it make you feel that this whole thing is not consistent.

I just wanted to share my thoughts but I think for this filed Issue here, the PR you created is great to solve cx problem and good enough to close this Issue. Thank you

[jeremymeng]

Just kindly note one thing. The C# while it can receive the messages. It has a weird behavior. When the message is received to process if you check the session id, you will see it is null and not an empty string. So all in all it make you feel that this whole thing is not consistent.

Yes, the C# client normalizes empty string to null before sending requests to the service.