The grpc_detection classifier filter records its result only into filter_metadata and filter_results. The router matches on headers, so it cannot consume either of those, which means a request cannot actually be routed on the outcome of gRPC detection. This contradicts the filter's own rustdoc, which presents it as a classifier usable in the standard classify then route flow, and it diverges from the project's documented pattern where classifier filters promote facts to reserved x-praxis-* headers that the router then matches to select a cluster.
So today an operator following the rustdoc will wire up grpc_detection ahead of a router match and find that the match never fires, with no error, because the fact was never placed anywhere the router can see.
This needs a decision on intended behavior before a fix. There are two clean resolutions. Either the filter should also promote its result to a reserved x-praxis-* header (consistent with the other classifiers, so routing on gRPC detection works as the rustdoc implies), or, if promotion to a header is deliberately out of scope, the rustdoc should be corrected to stop implying router-based routing and instead point at the branch-chain path that does consume filter_results.
This is thematically adjacent to the classifier-namespace concern in #1057 (which is about promotions landing in non-reserved, client-spoofable header names), but it is a distinct problem: here the issue is that nothing is promoted to a header at all. Found during reconciliation of the crate-by-crate audit; not currently tracked.
The
grpc_detectionclassifier filter records its result only intofilter_metadataandfilter_results. The router matches on headers, so it cannot consume either of those, which means a request cannot actually be routed on the outcome of gRPC detection. This contradicts the filter's own rustdoc, which presents it as a classifier usable in the standard classify then route flow, and it diverges from the project's documented pattern where classifier filters promote facts to reservedx-praxis-*headers that the router then matches to select a cluster.So today an operator following the rustdoc will wire up
grpc_detectionahead of aroutermatch and find that the match never fires, with no error, because the fact was never placed anywhere the router can see.This needs a decision on intended behavior before a fix. There are two clean resolutions. Either the filter should also promote its result to a reserved
x-praxis-*header (consistent with the other classifiers, so routing on gRPC detection works as the rustdoc implies), or, if promotion to a header is deliberately out of scope, the rustdoc should be corrected to stop implying router-based routing and instead point at the branch-chain path that does consumefilter_results.This is thematically adjacent to the classifier-namespace concern in #1057 (which is about promotions landing in non-reserved, client-spoofable header names), but it is a distinct problem: here the issue is that nothing is promoted to a header at all. Found during reconciliation of the crate-by-crate audit; not currently tracked.