envoyproxy/envoy

fix_format doesn't uniquely identify absolute protobuf message names

Open

#17,216 创建于 2021年7月1日

在 GitHub 查看
 (1 评论) (0 反应) (0 负责人)C++ (5,373 fork)batch import
area/buildbughelp wanted

仓库指标

Star
 (27,997 star)
PR 合并指标
 (平均合并 8天) (30 天内合并 378 个 PR)

描述

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

贡献者指南