Although it is not the first time that I stumble over the nullability feature and breaking changes, this one still caught me by surprise. Let me first explain the context; I have an application built in ASP.NET Core with the nullability feature still disabled. As I had to make some changes to the API, I though it was a good timing to enable the nullability feature to help me avoid nullreference exceptions.
As always I started by updating the application to enable the nullability feature. Therefore set the nullable value to enabled inside the csproj file:
After enabling the feature, our integration tests started to fail. Here is the specific error message that got returned:
In our API we have the option to pass an optional(!) X-Environment header parameter. We use this attribute to avoid that the API is accidently called from our development or test environment. In our original API implementation this attribute is optional; in case the attribute is ommitted we don’t do the environment check.
This is the original controller method:
After enabling nullability, the environment header is no longer optional resulting in a change in behaviour. Unfortunately, this change is not visible in the OpenAPI metadata as in both cases the metadata remains the same:
To keep the original behavior, we need to update the controller method like this:
Makes sense of course, but still an easy mistake to make. Another good reason why having a good set of integration tests is important.