The BodyTopLevelProperties rule is mistakenly flagging paged responses

[markcowl]

Describe the bug
The BodyTopLevelProperties check is incorrectly flagging the response in List operations, which rturn a page of data as if they were resource GET operations. There are several examples in this PR: https://github.com/Azure/azure-rest-api-specs-pr/pull/18696
To Reproduce
Steps to reproduce the behavior:
Create list operations like: https://github.com/Azure/azure-rest-api-specs-pr/blob/a6bade603572212620a6cbb906f400e19d899b1b/specification/edge/resource-manager/Microsoft.Edge/configurationmanager/preview/2024-06-01-preview/configurationmanager.json#L62-L99

Expected behavior
This check should not be applied to list operations at all - in ARM specs, having an odd number of PATH segments and a last segment that is not a path variable should prevent the rule from being applied

Screenshots
See the link above.

Desktop (please complete the following information):
n/a, this occurs in CI

Additional context

[dhruvesh]

I am facing same issue: Azure/azure-rest-api-specs#29961

[sdorbala]

I'm facing the same issue on my PR https://github.com/Azure/azure-rest-api-specs-pr/pull/19036

[arjun-d-patel]

Same issue in: Azure/azure-rest-api-specs#29998 and https://github.com/Azure/azure-rest-api-specs-pr/pull/18922

[pjhanwar]

Facing same issue in https://github.com/Azure/azure-rest-api-specs-pr/pull/18985

[JoseLimaIVD]

Facing the same issue in https://github.com/Azure/azure-rest-api-specs-pr/pull/18871

[rosychen427]

facing the same issue: https://github.com/Azure/azure-rest-api-specs-pr/pull/19088

[arjun-d-patel]

Same issue here: Azure/azure-rest-api-specs#30271

[priyankarking]

I am facing same issue Azure/azure-rest-api-specs#30293

[priyankarking]

how to suppress this issue or make it optional ?

[mikeharder]

Fixed by #729

[mikeharder]

Fix #729 requires the path after the last . to contain an even number of path segments:

azure-openapi-validator/packages/rulesets/src/native/utilities/rules-helper.ts

Lines 140 to 152 in c26c69a

	export function isListOperationPath(path: string) {
	if (path.includes(".")) {
	// Get the portion of the api path to the right of the provider namespace by splitting the path by '.' and taking the last element
	const splitNamespace = path.split(".")
	if (path.includes("/")) {
	const segments = splitNamespace[splitNamespace.length - 1].split("/")
	// If the last segment split by '/' has even segments, then the operation is a list operation
	if (segments.length % 2 == 0) {
	return true
	}
	}
	}

Which fixed cases like this:

https://github.com/Azure/azure-rest-api-specs-pr/blob/b928ddf9ff0b8a721fe51b8694276e2a864e2982/specification/edge/resource-manager/Microsoft.Edge/configurationmanager/preview/2024-06-01-preview/configurationmanager.json#L322

However, we have an example of a spec with an odd number of path segments instead:

https://github.com/Azure/azure-rest-api-specs-pr/pull/19621/files#diff-25d510d5d4b2927e4a5e839a6258baf6c9f7be821f48e3b7602383fb67647acfR125

Should the rule be fixed to allow this path? Or is the rule correct, and the spec should be updated to use an even number of path segments?