Goals

• Make it easier for operators to understand filter chain dependencies. Ordering dependency is often implicit and discovered by trial-and-error or imitating examples.
• Improve safety of filterchain configurations and rollout by enforcing filter dependencies.
• Handle missing dependencies in a consistent way across filters, and increase validation for custom header dependencies (i.e. implicit router filter dependencies).

Requirements

• Catch code and config changes that break interfilter dependencies.
• Dependencies are defined in a way that supports documentation flow, so filter documentation includes dependency metadata in a human-readable form.
• Do not impose undue complexity or config burden to operators who don’t need this. The dependency mechanism should be optional and opt-in.
• Handling of dependency violations should be explicit and well-defined.
• Support directionality, i.e. specify separate dependencies for the encode and decode path.
• Support multiple kinds of dependencies (e.g. FilterState, DynamicMetadata, headers)
• The implementation should be simple enough that we don’t cause more problems than we prevent.

Design Proposal

tl;dr Introduce a filter dependency proto by which a filter can specify what it depends and provides. The dependency specification includes specifying dependencies and "providencies", encode and decode path, and currently three kinds of dependencies (FilterState keys, headers, and DynamicMetadata). The dependency spec will be an optional function in the filter FactoryBase, which a FilterFactory can override to include dependencies, either simply by parsing a .pb_text or with more complex modifications and config-time data. The filterchain will be assessed after the instantiation of FilterFactories, and if the chain is invalid the config is rejected.

Full design doc. Feel free to leave comments on the doc or reply here.