[config] Add validation to ConfigClient/ConfigAsyncClient to ensure the transport is compatible

[jhollowe]

Determine this is the right repository

• I determined this is the correct repository in which to report this feature request.

Summary of the feature request

Since the ConfigAsyncClient appears to only correctly function with the grpc_asyncio transport, it would be useful to validate that the sync-or-async of the transport matches the sync-or-async of the Client.

Desired code experience

file: main.py

   def my_ideal_error_checking():
     ConfigClient(..., transport="grpc_asyncio") # ERROR
     ConfigAsyncClient(..., transport="grpc")    # ERROR
     ConfigAsyncClient(..., transport="rest")    # ERROR

     ConfigAsyncClient(..., transport="grpc_asyncio")    # Success!

Expected results

Creating a ConfigClient with an async transport or creating a ConfigAsyncClient with a synchronous transport would raise an exception.

API client name and version

google-cloud-config==0.1.17

Use case

This will prevent unnecessary troubleshooting of later issues which arise from incompatible transports.

Additional context

No response

[jhollowe]

Any update on this? It has been 3 months with no movement.

[jhollowe]

One month later and no updates. Please triage this issue.

[jhollowe]

It has been over 8 months since this issue was opened. Please triage and fix this issue.
@parthea can I get some traction on this?

[parthea]

@chalmerlowe, Please could you take a look?

[chalmerlowe]

I am triaging this request to see the scope of the work (i.e. this is autogenerated code, so we would need to go upstream to modify the configs to cleanly generate the desired results and the unit tests) and consider that in light of our other priorities across the CLOUD SDK ecosystem. More to come.

[chalmerlowe]

@jhollowe

I have an experimental PR in the works to see if this is doable and reasonable.

For context and to manage expectations:

• The code in google-cloud-config is autogenerated based on a set of templates, proto files, and yaml files.
• By and large the templates are used universally across hundreds of libraries so it is difficult to change them without breaking all the things
• The proto files are easier to update, but are often focused on the specifics of the APIs the library interacts with
• The yaml file is more focused on some of the specifics of the library, but it is still complicated to get all the parts to align so that the yaml and protos can be ingested to feed the generator and filter down into the templates and create the output we desire.

If the CLOUD SDK team compares this with our other priorities and decides to pursue this, it will require some time and effort to do this right.

Are there specifics you can share that might highlight why this validation check should be prioritized? Having that would be useful to consider in our deliberations.

I have not looked at your other issue yet, but the same considerations will apply.