Ambiguous Method Calls in Auto-Generated Test Code

[rohitsinghal4u]

Hi,

I'm reporting a bug in the auto-generated test files that prevents compilation when multiple convenience method overloads exist.

Issue Description:
When the generator creates test files for operations with pagination parameters, it generates method calls with null parameters that result in ambiguous method call errors during compilation.

PR: https://github.com/Azure/azure-rest-api-specs/pull/40714/changes

Location:

Repository: azure-rest-api-specs
Specification: KeyVault Certificates (2025-06-01-preview)
Generated test files:
GetCertificateIssuersTests.java
GetCertificateVersionsTests.java

Problem Details:
The generator creates overloaded convenience methods in the client:
// Both methods exist:

1. getCertificateIssuers(RequestOptions requestOptions) // Low-level API
2. getCertificateIssuers(Integer maxresults) // Convenience method

But the generated test calls them with null:
PagedIterable response = keyVaultClient.getCertificateIssuers(null);

This creates an ambiguous method reference compilation error because null can match either parameter type.

Expected Behavior:
Generated tests should either:

• Use the parameterless convenience method overload (if available), or
• Pass the correct typed parameter, or
• Explicitly cast the null to avoid ambiguity

Reproducibility:
Generate Java SDK from KeyVault Certificates specification (API version 2025-06-01-preview) and run mvn test on the generated project.

[weidongxu-microsoft]

Thanks @rohitsinghal4u for the report and thoughtful suggestions!

I think "Explicitly cast the null to avoid ambiguity" likely be the easiest solution.

The "Pass the correct typed parameter" didn't happen, likely because that the JSON example in specs repo does not have this Integer parameter (otherwise, emitter would use that value).

Meantime, before emitter fix, you can delete the tests that fails compilation. They are mostly for reference when you plan to write LIVE tests.

[weidongxu-microsoft]

BTW, when I test on regen of SHA at Azure/azure-rest-api-specs#40714
on sdk/keyvault/azure-security-keyvault-certificates

I would get a compilation error on source

[ERROR] /C:/github/azure-sdk-for-java/sdk/keyvault/azure-security-keyvault-certificates/src/main/java/com/azure/security/keyvault/certificates/models/CertificateOperation.java:[133,29] incompatible types: com.azure.security.keyvault.certificates.implementation.models.KeyVaultErrorError cannot be converted to com.azure.security.keyvault.certificates.models.CertificateOperationError

then tons of error in tests/samples.

---

If that many test compilation failure occurs to you as well (likely due to code customization). You may prefer to turn them off at tspconfig.yaml

generate-samples: false
generate-tests: false

[rohitsinghal4u]

Thank you @weidongxu-microsoft for the prompt response. I am compiling sdk directly from the path: azure-rest-api-specs\specification\keyvault\Security.KeyVault.Certificates\tsp-output\sdk\keyvault\azure-security-keyvault-certificates
with
mvn clean compile
I don't see any compilation error.

Is it ok to make generated-tests : false and update the PR?

Just curious to know how the SDK code will work in the production by which generator creates, if it has a compilation error?

[weidongxu-microsoft]

Yeah, feel free to do generate-tests: false

The SDK code is not incorrect. 2 methods have different method signature.

The ambiguous is on the code used in test. When written as getCertificateIssuers(null) compiler does not know which method to call. User probably would just write getCertificateIssuers(), if they want to do same.