[Davide Montanari (davidemontanari)]

Summary

MessageSender.SendAsync(IEnumerable<Message>) adds every message to a single ServiceBusMessageBatch and ignores the result of TryAddMessage. Any message that doesn't fit in the batch is never sent, and nothing records it.

This PR makes these drops visible.

Changes

• When one or more messages don't fit in the batch, an Error trace is written with event type MessageSender-SendAsync-MessagesDropped. It includes:
  • the entity path
  • the number of dropped messages and their total body size in bytes
  • the number of messages added to the batch
  • the maximum batch size in bytes
• The trace has a fixed size, so it is never truncated by the event source's field size limit, however many messages are dropped.
• The message batch is now disposed after it is sent.

Behaviour

• Messages that fit in the batch are sent in a single batch with one send call.
• Messages that don't fit are not sent; the trace records how many were dropped.
• If every message fits, no trace is written.

Notes

All messages in one call share a single batch (256 KB on Standard, 1 MB on Premium), even though each message on its own stays below MessageOverflowThresholdInBytes (170 KB by default). Large fan-outs can exceed the batch size: many activities scheduled in one episode, or the matching history tracking messages. When that happens, the extra messages are dropped and the new trace records them.

Testing

• DurableTask.ServiceBus builds with no warnings or errors.

[azure-pipelines]

Azure Pipelines:
There may be pipelines that require an authorized user to comment /azp run to run.

[Copilot]

🟡 Changes recommended

Large dropped-ID lists are truncated by the tracing layer, leaving the intended diagnostics incomplete.

2 open issues

• Chunk dropped-ID traces to avoid silent truncation · New
• Avoid claiming batch messages were sent before delivery · New

What changed in this PR

This PR adds visibility into messages dropped by the Service Bus provider when they exceed a single batch’s capacity, without changing the existing single-batch send behavior.

Changes:

• Adds error tracing with dropped-message counts, body bytes, IDs, and batch context.
• Disposes the message batch after use.
• Documents that messages exceeding batch capacity are traced but not sent.

File	Description
src/​DurableTask.ServiceBus/​Common/​Abstraction/​ServiceBusAbstraction.cs	Adds overflow diagnostics, batch disposal, and method documentation.

_{Review effort: Balanced}

[Copilot]

🟢 Approval recommended

The focused changes preserve existing sending behavior and introduce no identified blocking issues.

No open issues 🎉

2 resolved since last review

• Chunk dropped-ID traces to avoid silent truncation
• Avoid claiming batch messages were sent before delivery

_{Review effort: Balanced}

[Bernd Verst (berndverst)]

No actionable correctness bugs or regressions found. The change logs messages rejected by TryAddMessage through the existing tracing mechanism and disposes the batch after the awaited send, without changing the existing single-batch delivery behavior. Oversized or overflow messages are still omitted as before; this PR adds diagnostics rather than fixing that pre-existing delivery limitation.

Reviewed the batching loop, message conversions, caller transaction flow, and error-event routing. The Service Bus project builds successfully with zero warnings or errors. No live Service Bus validation was performed, and the PR adds no tests for partial/all-rejected batches or the emitted log contents.