Fix nullability of return types that can be non-null

[IvovdBruggen]

This fixes #15926

Changes

Fixes nullability of methods exposed in various Umbraco extensions.

[github-actions]

Hi there @IvovdBruggen, thank you for this contribution! 👍

While we wait for one of the Core Collaborators team to have a look at your work, we wanted to let you know about that we have a checklist for some of the things we will consider during review:

• It's clear what problem this is solving, there's a connected issue or a description of what the changes do and how to test them
• The automated tests all pass (see "Checks" tab on this PR)
• The level of security for this contribution is the same or improved
• The level of performance for this contribution is the same or improved
• Avoids creating breaking changes; note that behavioral changes might also be perceived as breaking
• If this is a new feature, Umbraco HQ provided guidance on the implementation beforehand
• 💡 The contribution looks original and the contributor is presumably allowed to share it

Don't worry if you got something wrong. We like to think of a pull request as the start of a conversation, we're happy to provide guidance on improving your contribution.

If you realize that you might want to make some changes then you can do that by adding new commits to the branch you created for this work and pushing new commits. They should then automatically show up as updates to this pull request.

Thanks, from your friendly Umbraco GitHub bot 🤖 🙂

[IvovdBruggen]

Realising now that this is a very small pull request, does it sound good that I also fix all the other nullability return warnings? Excluding obsolete methods that is.

[georgebid]

Hey @IvovdBruggen! Thank you for your PR to fix #15926, someone on the team will review this soon 😄 and in terms of creating a new issue, it's up to you really, you could either create a new one or add on to 15926, and then you could update your PR too 😄 And I agree, probably best to leave anything that is obsolete.

[IvovdBruggen]

@georgebid Great! I have updated the issue and PR and will commit the other fixes!

[IvovdBruggen]

Any progress on this perhaps? Came by the same issue today

[georgebid]

Hey @IvovdBruggen, sorry for the delay on this one. We are doing a cleanup of older PRs, would you mind fixing the merge conflicts then we will make sure this gets reviewed, and hopefully merged! Again, sorry for the delay!

[IvovdBruggen]

Hi, no problem! I'll get around to fixing the conflicts.

[IvovdBruggen]

Hope I did the rebasing right, never did it before on a project this scale 😁

[AndyButland]

Thanks for the efforts on this @IvovdBruggen. I've had a look at resurrecting it - I know it's been a while, but there are some nice updates in here that I agree would be good to include.

I've pushed a few updates in case you'd like to comment:

• Merged latest from main.
• Reverted a few updates that meant we had different nullability for return types on the implementation and the interface or base class. Whilst the implementations of for example particularly property value converters may be marked as not returning null, it felt to me that it was better to be consistent with the interface or base class.
• In other cases though, it did seem better to make the nullability change to the interface too - particularly for collections. It's better practice here to return empty collections over null values. So I've done that too.

For the latter case this will mean breaking changes, so it'll be best to include this for Umbraco 17.

I'll take this to the team in HQ to get some further opinions on how best to handle this, but assuming you agree with the changes, we could re-target this to v17/dev and include for the next major release.

[IvovdBruggen]

Hi @AndyButland, thanks for taking a look! I am currently on holiday but what you say seems good. As for Umbraco 17 release, thats good. At the moment I don't work alot with Umbraco so whenever's good.

[Copilot]

Pull Request Overview

This PR fixes nullability annotations for return types across the Umbraco codebase that were incorrectly marked as nullable when they can actually return non-null values. The changes ensure proper type safety and better developer experience by correctly indicating when methods will always return non-null values.

Key changes:

• Remove nullable annotations (?) from return types that never return null
• Update method signatures in interfaces and implementations to match
• Fix inconsistencies between base classes and derived classes

Reviewed Changes

Copilot reviewed 154 out of 154 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
Various webhook event classes	Remove nullable return types from ConvertNotificationToRequestPayload methods that always return objects
Extension classes	Remove nullable annotations from methods like Name, Children, Siblings that return non-null collections/strings
Service interfaces and implementations	Fix return types for methods like GetActiveServers, GetMembersByPropertyValue that return non-null collections
Property value converters	Correct nullability of conversion methods based on actual return behavior
Utility and extension classes	Update return types for helper methods that guarantee non-null results

[AndyButland]

Thanks again @IvovdBruggen - as mentioned above, we'll merge this in but keep it for Umbraco 17 due to the minor breaking changes introduced by these nullability updates.

[ronaldbarendse]

@AndyButland Removing nullability from the abstract/virtual WebhookEventBase<TNotification>.ConvertNotificationToRequestPayload() return type should be reverted, because although the CMS never returns a null value in its own concrete implementations, other implementations might. Also IWebhookFiringService.FireAsync() still accepts a nullable payload, so it should be valid to return null from this method, right?

[AndyButland]

Thanks @ronaldbarendse - I've addressed with #20660.