[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.

[daniel-sanche]

Personally, I don't think we should be making this change. This is a power-user feature, most users should not be changing the transport class at all. If anything, maybe we can just update the docstring to more strongly discourage changing this field?

If we did want to add validation, maybe we could use a separate metaclass transport registry? We currently have one shared metaclass for the sync client, so all transports show up in the same registry. Or we could just add that _allow_async_transport flag to the existing one

@jhollowe if you have more context on the issue you ran into and what you were trying to accomplish with a transport override, that could be helpful deciding how to proceed