Autorest: c# validation nullable value

[audunn]

Hi,
We have a swagger spec with a value that is conditional/optional i.e. can be null with some validation constraints this is presented like so:

        "totalThroughputMibps": {
          "type": "number",
          "x-nullable": true,
          "description": "Total throughput of pool in Mibps",
          "example": 164.221,
          "readOnly": true,
          "multipleOf": 0.001
        }

This causes issues with c# generated SDK where the validation code does not allow null values.

            public double? TotalThroughputMibps { get; private set; }
.
.
.
.
.
            if (TotalThroughputMibps % 0.001 != 0)
            {
                throw new ValidationException(ValidationRules.MultipleOf, "TotalThroughputMibps", 0.001);
            }

Is it possible to present this in the swagger so that the validation in the generated code handles null values correctly?

[johanste]

Why is the value sent with a null value from the service rather than the key/value being omitted alltogether? In general, I recommend that a service should avoid semantically meaningful null values and rather use optional fields for "things that have no value". And, yes, I know that doesn't directly address your question - but if you happen to own the service API, you may be able to side-step the problem by marking the property optional instead.

[johanste]

...and why does the code generated using the C# code generator ever run validation on a readOnly value?

[audunn]

The issue is client side, f.ex. when creating the parent resource and with validation like this the user/caller cannot construct the parent object without initializing this property that is not required i.e. not mandatory as it is nullable.
I cannot see why the validation is implemented like this, readonlydoes not seem to affect this behavior it does the same validate regardless if we keep that in or not.

To be clear I am mostly interested in what would be the correct/best way to do this.

The issue/question may be tied to numbers and/or multipleOf constraints as we see this behave differently with strings elsewhere in the spec. Where this specification:

        "adName": {
          "type": "string",
          "maxLength": 64,
          "minLength": 1,
          "description": "Name of the active directory machine. This optional parameter is used only while creating kerberos volume",
          "example": "ADServerName"
        },

Generates this validation:

            if (AdName != null)
            {
                if (AdName.Length > 64)
                {
                    throw new ValidationException(ValidationRules.MaxLength, "AdName", 64);
                }
                if (AdName.Length < 1)
                {
                    throw new ValidationException(ValidationRules.MinLength, "AdName", 1);
                }
            }

[audunn]

Sitting for a while now is there a way to get issue looked at here?

[srchilu]

We are facing similar issue in office machines (msft) while generating c# sdk.
autorest version:
core @autorest/core 3.0.6274 C:\Users\srchilu.autorest\@[email protected]
AutoRest code generation utility [cli version: 3.0.6187; node: v12.19.0, max-memory: 8192 gb]

Seen this issue with both .net core 3.1.9 and 3.1.8 versions.

[daviwil]

@srchilu Can you provide an example of how you're invoking AutoRest when you see this issue?

[priyankajayaswal1]

We are invoking it by using the following command.
autorest --csharp --v3 --input-file=docs\open-api-specs\latest\swagger.json --output-folder=service_client --verbose --namespace=auto_generated --version=3.0.6274
This is the exact command we use. The behavior seems to be inconsistent when running in office systems (msft ) and when running in my laptop.

[priyankajayaswal1]

@daviwil can you have a look at it, since we are really dependent on autorest to not change it's behavior and break things in between for our system to work. This looks more of a regression issue (not sure of what exactly). Adding a snippet on how is the change breaking things for nullable entities.

Without the null checks the created csharp client using command:

autorest --csharp --v3 --input-file=docs\open-api-specs\latest\swagger.json --output-folder=service_client --verbose --namespace=auto_generated --version=3.0.6274

is bound to not be robust. We really need this to resolve ASAP. You may reach out to me at alias: prjayasw on MSTeams

[pakrym]

@priyankajayaswal1 can you clarify why the code change you included is breaking?

[pakrym]

As to the original issue in this thread, I believe it's fixed as part of https://github.com/Azure/autorest.csharp/issues/885.

Try adding --use:@microsoft.azure/[email protected] to your command line.

[priyankajayaswal1]

@pakrym above links exactly what we wanted to have resolution for. I somehow ended on this thread. But thanks for sharing the details. Above resolves my issue.
Just curious what made the default behavior to break exactly. Any idea?

[pakrym]

Just curious what made the default behavior to break exactly. Any idea?

I'm sorry, I don't fully understand the question.

[priyankajayaswal1]

What caused bug Azure/autorest.csharp#885?

[pakrym]

We didn't generate a null-check before trying to validate nullable properties using the % operator causing the generated code not to compile.

[daviwil]

@audunn Does the above resolution fix your issue?

[audunn]

@daviwil apologies for the late reply, yes indeed this does seem to fix the issue.