envoyproxy/envoy

fix_format doesn't uniquely identify absolute protobuf message names

Open

#17,216 opened on Jul 1, 2021

View on GitHub
 (1 comment) (0 reactions) (0 assignees)C++ (5,373 forks)batch import
area/buildbughelp wanted

Repository metrics

Stars
 (27,997 stars)
PR merge metrics
 (Avg merge 8d) (378 merged PRs in 30d)

Description

We currently have the following structure inside of envoy.extensions.transport_sockets.tls.v3.CommonTlsContext:

In #17201, I am moving the CertificateProviderInstance out of CommonTlsContext. In order to not break API compatibility, I need to leave the existing CertificateProviderInstance message and the field that uses it intact but deprecated, copy the message to the new location, and add new fields that use the message in the new location.

So I created the new message and added the following new field in CommonTlsContext:

.envoy.extensions.transport_sockets.tls.v3.CertificateProviderPluginInstance tls_certificate_provider_instance = 15;

That uses the full path of the proto to differentiate between the new version of the CertificateProviderPluginInstance message that exists outside of the CommonTlsContext proto from the old version that exists inside of CommonTlsContext. However, fix_format changed it to use the latter instead of the former:

CertificateProviderInstance tls_certificate_provider_instance = 15;

It seems that fix_format can't tell that CertificateProviderInstance exists both inside and outside of CommonTlsContext and that I wanted to refer to the one that is outside.

For now, I've worked around this by simply using a different name for the new message (CertificateProviderPluginInstance instead of CertificateProviderInstance). But I think we should fix fix_format to not require that.

CC @htuch

Contributor guide