Service bus queues using sessions allow you to insert an empty session after a few attempts via the Azure panel.

👁 User's image

When this happens, the queue stops and no more messages are consumed, so I end up having to delete the queue and create it again.

Is this an Azure bug?

0 comments No comments
Sign in to comment

Answer accepted by question author

Rakesh Mishra 9,695 Reputation points • Microsoft External Staff • Moderator

Hi Jose,

Welcome to the Microsoft Q&A Platform! Thank you for asking your question here.

I was also able to add the queue message with blank session id just after adding message with session id.

I have shared the feedback with the internal Service Bus team, and they acknowledged that issue. They are working on fixing it and will release soon. There is no ETA provided at this moment.

Currently, it should timeout on this session and moved to next one.

Let me know if you need any other information on this.

  1. Rakesh Mishra 9,695 Reputation points • Microsoft External Staff • Moderator

    Hi Jose, please find the response above. Also, let me know if you have any questions. Please accept 👁 User's image
    the answer as it may help other community members.

Sign in to comment

1 additional answer

  1. AI answer

    This behavior is expected when sessions are enabled, not an Azure bug.

    When sessions are enabled on a queue or subscription, all messages must be sent and received as part of a session. This is enforced by the platform:

    • A sender must set a session ID on every message.
    • A receiver must accept a session and then read messages from that session.
    • Once a session is accepted, the receiver holds an exclusive lock on all messages with that session ID until the session is closed or the lock expires. Messages for that session are delivered only to that receiver and in order.

    If a message is inserted with a missing or inconsistent session ID (for example, via the portal or a non‑session‑aware sender) while the entity has sessions enabled, client applications that expect valid sessions can stop processing correctly because:

    • Clients can no longer send or receive “regular” (non‑session) messages on a session‑enabled entity.
    • The processor may be waiting on a particular session and not move on if the session lock or idle timeout isn’t configured appropriately.

    To avoid having to recreate the queue:

    1. Ensure all messages sent to a session‑enabled queue include a valid session ID.
    2. Use a session receiver (or ServiceBusSessionProcessor) so that sessions are accepted and closed properly.
    3. Configure SessionIdleTimeout appropriately so the processor moves on to other sessions when one is idle.

    This is the designed behavior of Service Bus sessions to guarantee ordered, session‑scoped processing, not a platform defect.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.
Sign in to answer

Your answer