[BUG] Service Bus is not annotated for nullability

[vanillajonathan]

Library name and version

Azure.Messaging.ServiceBus 7.17.3

Describe the bug

The ContentType property of the ServiceBusReceivedMessage class is not declared as nullable but it can be null.

Expected behavior

The ContentType property should be declared as nullable.

public string? ContentType { get; set; }

Actual behavior

The ContentType property is not declared as nullable.

public string ContentType { get; set; }

Reproduction Steps

var message = await _receiver.PeekMessageAsync(123);
if (message.ContentType.StartsWith("application/"))
{
}

Environment

.NET 8.0.200

[jsquire]

Hi @vanillajonathan. Thank you for reaching out and we regret that you're experiencing difficulties. The Service Bus client library is intentionally not annotated for nullability. Nullable reference annotations are something that we continue to evaluate for Azure SDK packages as the language and tooling evolves, but not something that we'll be enabling in the short term. There are several reasons for this, the most important being:

• The Azure SDK strives to have a consistent set of patterns and feel across different libraries. As such, nullable reference annotations are not something that would be applied to individual libraries; it would be a decision that we need to apply to all of our current generation packages.

• For most of our libraries, the service definitions do not adequately document which fields may be null. We continue to work with our service partners to improve these definitions, but it's a large effort that we expect to continue for some time.

• Tooling still doesn't provide a thorough understanding of what breaking changes would be introduced by enabling nullable reference annotations. Avoiding breaking changes is one of the most important core tenants of the current Azure SDK generation; until we have confidence that we can prove that nullable reference annotations are safe for the public APIs that they were added to, the risk outweighs the reward.

Additional rationale and discussion can be found in #8880.

[github-actions]

Hi @vanillajonathan. 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.

[vanillajonathan]

/unresolve That issue is several years old. Now is new times so it ought to be reconsidered.

This caused a bug for me and having the library annotated for nullability would improve the developer experience and reduce downstream bugs.

The Azure SDK would continue to be consistent across different libraries even with nullability since the API and behavior would remain the same. Nullability is just a compiler hint.

[jsquire]

Adding nullability to an existing API that has been released is considered a breaking change and is not something that we would be adding in the current form. To avoid inconsistencies, we do not currently have plans to annotate new members in existing libraries. We are continuing to monitor changes in the .NET ecosystem and tooling and should a path become available to introduce annotations in a non-breaking way, we may reconsider at that point. At present, this is not something that we will be adding.

[github-actions]

Hi @vanillajonathan. 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.

[github-actions]

Hi @vanillajonathan, since you haven’t asked that we /unresolve the issue, we’ll close this out. If you believe further discussion is needed, please add a comment /unresolve to reopen the issue.