paging.member is erroneously kept when x-ms-paging.operationName is deleted via a transform

In the following config.

https://github.com/Azure/azure-rest-api-specs/blob/main/specification/policyinsights/resource-manager/readme.md

The x-ms-pageable.operationName is deleted via a transform for a few operations. While this removes the language.default.paging.nextLinkOperation from the model, the language.default.paging.member is still present.

The Go code generator uses the existence of language.default.paging.member to determine if a paged operation is to use a separate operation for fetching the next page. Maybe this is in error?

We can work around this easily enough by predicating on the existence of language.default.paging.nextLinkOperation. Just raising that there looks to be an inconsistency in this presumably rare case.

[timotheeguerin]

Yeah that assumption should be correct right now. I’ll look into the types/documentation for this. I do find it weird that all those links are under language feel like there should be a better dedicated property for it.

[jhendrixMSFT]

I am actually not fully sure what all those properties are meant to correspond to. There is no strong typing for it and no doc.

Initially, this was a bit of a problem for us and so we just reverse-engineered it based on our tests (not a great way to write software). Is there better data we should be looking at in the model for paged operations? If not, it would be nice to add strong typing and docs for it.

I’ve switched to predicate this on the existence of nextLinkOperation as I assume that if it exists then so will member. Assuming this is sane, no need to introduce a breaking change as this is a real corner-case (maybe doc this behavior).