Unrecognized proto options in service config cause the ESP service config reader to fail

[timburks]

While doing some experimentation with ESP, I recently encountered this error:

INFO:Constructing an access token with scope https://www.googleapis.com/auth/service.management.readonly
INFO:Service account email: stores@bobadojo.iam.gserviceaccount.com
INFO:Refreshing access_token
INFO:Fetching the service config ID from the rollouts service
INFO:Fetching the service configuration from the service management service
nginx: [warn] Using trusted CA certificates file: /etc/nginx/trusted-ca-certificates.crt
2024/11/19 22:00:02[error]1#1: Cannot load ESP configuration protocol buffer.
nginx: [emerg] Failed to load service configuration files in /etc/nginx/endpoints/nginx.conf:112
nginx: [emerg] There were errors with Endpoints api service configuration.

The error message only occurs once in the code,
here:

bool Config::LoadService(ApiManagerEnvInterface *env,
                         const std::string &service_config) {
  if (!service_config.empty()) {
    if (!ReadConfigFromString(service_config, &service_)) {
      env->LogError("Cannot load ESP configuration protocol buffer.");
      return false;
    }

After confirming that ESP was getting the service config that I intended, I began experimenting with removing various elements, until I eventually found that the failure was occurring due to these two options in the "types" section of the service config:

$ diff original.config working.config 
125,138d123
<       "options": [
<         {
<           "name": "google.api.resource",
<           "value": {
<             "@type": "type.googleapis.com/google.api.ResourceDescriptor",
<            ...
<           }
<         }
<       ],
359,365d343
<               }
<             },
<             {
<               "name": "google.api.resource_reference",
<               "value": {
<                 "@type": "type.googleapis.com/google.api.ResourceReference",

These options come from AIP-122, which appeared much later than ESP, and probably are of no use to ESP. So perhaps these should be excluded from service compilation.

Regardless, this is brittle behavior for ESP and causes it to fail for service config that ESPv2 handles without a problem.