Repository: envoyproxy/envoy
File: api/envoy/extensions/dynamic_modules/v3/dynamic_modules.proto (Protocol Buffers)

Code before:
// Configuration of a dynamic module. A dynamic module is a shared object file that can be loaded via dlopen
// by various Envoy extension points. Currently, only HTTP filter (envoy.filters.http.dynamic_modules) is supported.
//
// How a module is loaded is determined by the extension point that uses it. For example, the HTTP filter
// loads the module with dlopen when Envoy receives a configuration that references the module at load time.
// If loading the module fails, the configuration will be rejected.
//
// Whether or not the shared object is the same is determined by the file path as well as the file's inode depending
// on the platform. Notably, if the file path and the content of the file are the same, the shared object will be reused.
//
// A module must be compatible with the ABI specified in :repo:`abi.h <source/extensions/dynamic_modules/abi.h>`.
// Currently, compatibility is only guaranteed by an exact version match between the Envoy
// codebase and the dynamic module SDKs. In the future, after the ABI is stabilized, we will revisit
// this restriction and hopefully provide a wider compatibility guarantee. Until then, Envoy
// checks the hash of the ABI header files to ensure that the dynamic modules are built against the
// same version of the ABI.
message DynamicModuleConfig {
  // The name of the dynamic module. The client is expected to have some configuration indicating where to search for the module.
  // In Envoy, the search path can only be configured via the environment variable ``ENVOY_DYNAMIC_MODULES_SEARCH_PATH``.
  // The actual search path is ``${ENVOY_DYNAMIC_MODULES_SEARCH_PATH}/lib${name}.so``. TODO: make the search path configurable via
  // command line options.
  string name = 1 [(validate.rules).string = {min_len: 1}];

  // Set true if the dynamic module is a terminal filter to use without an upstream.
  // The dynamic module is responsible for creating and sending the response to downstream.
  bool terminal_filter = 2;

  // Set true to prevent the module from being unloaded with dlclose.
  // This is useful for modules that have global state that should not be unloaded.
  // A module is closed when no more references to it exist in the process. For example,
  // no HTTP filters are using the module (e.g. after configuration update).
  bool do_not_close = 3;
}


Review comment (suggestion):
this should be in the http filter config, not the generic dynamicmoduleconfig here 
https://github.com/envoyproxy/envoy/blob/09bb59a13240e32e7d4ae2bd61c6ff91b0ab46d6/api/envoy/extensions/filters/http/dynamic_modules/v3/dynamic_modules.proto#L25

Code after:
// Configuration of a dynamic module. A dynamic module is a shared object file that can be loaded via dlopen
// by various Envoy extension points. Currently, only HTTP filter (envoy.filters.http.dynamic_modules) is supported.
//
// How a module is loaded is determined by the extension point that uses it. For example, the HTTP filter
// loads the module with dlopen when Envoy receives a configuration that references the module at load time.
// If loading the module fails, the configuration will be rejected.
//
// Whether or not the shared object is the same is determined by the file path as well as the file's inode depending
// on the platform. Notably, if the file path and the content of the file are the same, the shared object will be reused.
//
// A module must be compatible with the ABI specified in :repo:`abi.h <source/extensions/dynamic_modules/abi.h>`.
// Currently, compatibility is only guaranteed by an exact version match between the Envoy
// codebase and the dynamic module SDKs. In the future, after the ABI is stabilized, we will revisit
// this restriction and hopefully provide a wider compatibility guarantee. Until then, Envoy
// checks the hash of the ABI header files to ensure that the dynamic modules are built against the
// same version of the ABI.
message DynamicModuleConfig {
  // The name of the dynamic module. The client is expected to have some configuration indicating where to search for the module.
  // In Envoy, the search path can only be configured via the environment variable ``ENVOY_DYNAMIC_MODULES_SEARCH_PATH``.
  // The actual search path is ``${ENVOY_DYNAMIC_MODULES_SEARCH_PATH}/lib${name}.so``. TODO: make the search path configurable via
  // command line options.
  string name = 1 [(validate.rules).string = {min_len: 1}];

  // Set true to prevent the module from being unloaded with dlclose.
  // This is useful for modules that have global state that should not be unloaded.
  // A module is closed when no more references to it exist in the process. For example,
  // no HTTP filters are using the module (e.g. after configuration update).
  bool do_not_close = 3;
}