mgmt, investigate some failure with generated tests

[weidongxu-microsoft]

MQ (so not high priority)

https://github.com/Azure/autorest.java/wiki/Fluent-Codegen-Report/18fc73509fac4545216df8559b0c81f026e06b63

May start with keyvault and monitor (network maybe ignored, edge case of "NetworkManager" in model being ambiguous with our "###Manager"). But if this is certain edge case, ignore and proceed.

[XiaofeiCao]

Add failed case for datafactory:
log: https://dev.azure.com/azure-sdk/internal/_build/results?buildId=2002761&view=logs&j=12f1170f-54f2-53f3-20dd-22fc7dff55f9&t=dee4e6ec-be1b-5671-4678-ab293b4004c5&l=3241

example.json: https://github.com/Azure/azure-rest-api-specs/blob/main/specification/datafactory/resource-manager/Microsoft.DataFactory/stable/2018-06-01/examples/DataFlowDebugSession_AddDataFlow.json

generated code:

AddDataFlowToDebugSessionResponse response =
 manager
 .dataFlowDebugSessions()
 .addDataFlowWithResponse(
 "rvtwvyjprrxhxqp",
 "zzn",
 new DataFlowDebugPackage()
 .withSessionId("scswadvbwewwdf")
 .withDataFlow(
 new DataFlowDebugResource()
 .withName("kmhbeneq")
 .withProperties(
 new DataFlow().withDescription("hwmaxl").withAnnotations(Arrays.asList())))
 .withDataFlows(
 Arrays
 .asList(
 new DataFlowDebugResource().withName("odowsjcvpvtyull"),
 new DataFlowDebugResource().withName("cymnpblhal"),
 new DataFlowDebugResource().withName("catpwqoqnajmwpea"),
 new DataFlowDebugResource().withName("ggiglpg")))
 .withDatasets(
 Arrays
 .asList(
 new DatasetDebugResource().withName("ulugrumoprnboz"),
 new DatasetDebugResource().withName("xamhitqrpbwykee"),
 new DatasetDebugResource().withName("ps")))
 .withLinkedServices(Arrays.asList(new LinkedServiceDebugResource().withName("ko")))
 .withStaging(
 new DataFlowStagingInfo()
 .withLinkedService(
 new LinkedServiceReference()
 .withReferenceName("uvftkaaozpcc")
 .withParameters(mapOf()))
 .withFolderPath("datafqtq"))
 .withDebugSettings(
 new DataFlowDebugPackageDebugSettings()
 .withSourceSettings(Arrays.asList())
 .withParameters(
 mapOf(
 "wfdgeqzkpergzs",
 "dataydfmkz",
 "zudxqw",
 "datarkkankjk",
 "j",
 "datavxvoqbruyma"))
 .withDatasetParameters("dataofxirjfmvydjax"))
 .withAdditionalProperties(mapOf()),
 Context.NONE)
 .getValue();

[weidongxu-microsoft]

Likely cut-off by depth limit.

That would be a hard case.

[weidongxu-microsoft]

For ambiguous e.g. Context from azure-core and Context from service, we can let test always specify full namespace for Context from azure-core (no need to check if such case happens, just full namespace for all tests for all services)

[XiaofeiCao]

Add test file name too long, suppose we can trim the file name as we did to the example file names:
recoveryservicessiterecovery

[haolingdong-msft]

Test generation for mobilenetwork fails: https://dev.azure.com/azure-sdk/internal/_build/results?buildId=2070046&view=logs&j=12f1170f-54f2-53f3-20dd-22fc7dff55f9&t=dee4e6ec-be1b-5671-4678-ab293b4004c5

[XiaofeiCao]

Test generation for mobilenetwork fails: https://dev.azure.com/azure-sdk/internal/_build/results?buildId=2070046&view=logs&j=12f1170f-54f2-53f3-20dd-22fc7dff55f9&t=dee4e6ec-be1b-5671-4678-ab293b4004c5

Seems the same issue with this one.

[XiaofeiCao]

securityinsights has the same issue fixed here.

sql's issue is not generate-tests. It's more a specs issue. They have defined two identical extensible enums for one resource.
SqlVulnerabilityAssessmentName
VulnerabilityAssessmentName
The parameter names are the same, fluent gen will take one as class variable for resourceCreate and will result in mismatch of parameter type in generated code.
This exists in sql's preview version specs, and I think the issue can be solved by renaming these enums into one if they were going into stable version.

iotspaces's specs seems not correct. They don't have any operations: https://github.com/Azure/azure-rest-api-specs/blob/main/specification/iotspaces/resource-manager/Microsoft.IoTSpaces/preview/2017-10-01-preview/iotspaces.json I think we can ignore it.

Network's issue is xxxManager conflict. We ignore it?

[weidongxu-microsoft]

Sure, make sure general case is good. That should be enough.

[weidongxu-microsoft]

Likely cut-off by depth limit.

That would be a hard case.

Maybe we should use existing spec example JSON for the mock test, instead of generating mocked JSON.