azure-sdk-for-go: [datalake-store-filesystem] JSON Unmarshal for ACLStatus fails

The JSON Unmarshal for ACLStatus fails giving wrong results when calling GetACLStatus.

Fix: Change the type of Permission from int32 to string

type ACLStatus struct {
	Entries    *[]string `json:"entries,omitempty"`
	Group      *string   `json:"group,omitempty"`
	Owner      *string   `json:"owner,omitempty"`
	Permission *string   `json:"permission,omitempty"`
	StickyBit  *bool     `json:"stickyBit,omitempty"`
}


About this issue

  • Original URL
  • State: closed
  • Created 7 years ago
  • Comments: 19 (11 by maintainers)

Most upvoted comments

@amarzavery @fearthecowboy Thanks guys I’ve opened a specs PR to address this.

I think this is a spec bug

👍 for @amarzavery

This is absolutely a spec bug. If the content is a string, then we should absolutely not rely on lax behavior. Not all customers use AutoRest generated interfaces to talk to our services, and there is absolutely no benefit to having an incorrect OpenAPI spec and then relying on the deserializer to fudge the books.

If you want to prevent a breaking change in the other SDKs, there are ways to work around that.

I think this is a spec bug. The node sdk also expects a number. This will work for deserialization because the sdk is loose w.r.t type validation during deserialization (expect the server to do the right thing). However, this will not work during serialization as the type validation will fail.

IMHO, this should be modeled in the swagger spec as a "type": "string" and we should add support for "format": "octal". The swagger specification says that "format" is free form and additional values can be added. We already support "base64url" today (which is not a specified format in swagger 2.0 specification).

We should not rely on C# behavior because newtonsoft.json is too relaxed and tries to be too intelligent at times to predict what could be the actual value.

I think it would be better to make a breaking change and do the right thing i.e. support octal numbers.