When all model properties are optional, ArmPatchResourceSync/Async will not emit a new Update model

[zminot]

If all of the properties of a model are optional (?) and using ArmResourcePatchSync/Async, the emitter will not define and emit a new Update model to represent the PATCH operation. This results in what I think is improper spec (or, at least, azure-openapi-validator complains about it).

Playground Link

In the above playground, the patch expects the EmployeeUpdate which contains EmployeeProperties and the ManagedServiceIdentityUpdate. However, the properties of EmployeeProperties are all create/read-only properties. Removing the nullability of one of the properties--say, age--will instead prompt the emittance of EmployeeUpdate containing EmployeePropertiesUpdate, which in turn is defined with no properties (as nothing from EmployeeProperties should be able to be updated.

Not sure if this improper definition by us, though. We're running into RPC-Patch-V1-02 and RPC-Patch-V1-10 because of this.

[mikeharder]

Related, why does our own sample use ArmCustomPatchSync instead of ArmResourcePatchSync? Shouldn't our sample use the highest-level built-in types?

  update is ArmCustomPatchSync<
    Employee,
    Azure.ResourceManager.Foundations.ResourceUpdateModel<
      Employee,
      EmployeeProperties
    >
  >;

https://github.com/Azure/azure-rest-api-specs/blob/98d74b2db60e46ceb7e3b75755e51519cd500485/specification/contosowidgetmanager/Contoso.Management/employee.tsp#L59-L65

[markcowl]

Part of this is by design, and part is a bug

• PATCH requests should never have default properties, this is a bug
• However, having a write-once property with a default value is a really odd pattern -note that this indicates that the service sets this value if you do not provide it. Generally, write-once properties are required.
• readOnly properties are supposed to be skipped in requests by processors of the swagger, so provisioning state appearing as readOnly is expected (and funcionally equivalent to it not appearing)
• There isn't consensus on how to represent createOnly properties in Swagger, this is something we are actively talking about. The likely outcome is that these will occur in PATCH request schema and not be marked as nullable.

[markcowl]

• repurposing this to cover the 'default value' issue - we should produce PATCH schemas without default values