Aias00 opened a new issue, #7922: URL: https://github.com/apache/shenyu/issues/7922
## Goal Provide a read-only explanation of how a hypothetical request matches a selected gateway's current configuration. Operators should be able to answer why a request matched or missed a selector/rule without sending it to an upstream or inferring the decision from verbose logs. Example: enter GET /orders/42 with headers/query values. Show the considered plugins, selector/rule conditions, priority decisions, default-rule behavior and final matching result, together with the configuration snapshot used for the explanation. ## First deliverable - A diagnostic API and report model; an Admin UI can consume the same result in a coordinated follow-up. - Input: URI, method, relevant headers/query/cookies and explicitly supported routing context. - Select a gateway instance and identify its namespace, configuration source and available group revision/digest. Distinguish node-local configuration from Admin's desired configuration. - Explain plugin enablement/order, selectors considered, each condition result, matching specificity/sort, chosen rule, default-rule behavior, and no-match cases. - Report unsupported or unavailable context explicitly. Do not guess outcomes for arbitrary custom predicates, body-dependent logic, authentication decisions or remote calls. - Show eligible upstream candidates and the configured load-balancing policy where available. Do not claim a hypothetical exact selection by advancing stateful round-robin counters or consuming circuit-breaker recovery probes. ## Execution boundaries Reuse the production matching semantics, including compound conditions and RESTful matching; avoid a separately implemented approximation that drifts from the gateway. The diagnostic path must not execute normal plugin side effects, forward HTTP/RPC requests, change configuration, populate request-match caches, advance load-balancer counters, reserve breaker probes, or debit request/token budgets. Redact sensitive input values in stored/shared reports and bound input/report sizes. ## Acceptance criteria - [ ] Match results agree with normal gateway matching for supported conditions on the same configuration snapshot. - [ ] Cover exact/prefix/regex/pathPattern, mixed header/query conditions, AND/OR, enabled/disabled entries, specificity/sort, RESTful parameters and default rules. - [ ] Explain both matched and unmatched cases, including which earlier candidate won and why. - [ ] Same path with different headers/query values produces independently correct reports. - [ ] Clearly label stale/unknown/unsupported context and config changes during an inspection; never present mixed snapshots as one atomic revision. - [ ] Prove no outbound call and no mutation of matching/load-balancing/breaker/budget state. - [ ] Namespace and selected-node isolation, bounded work and access control are tested. ## Existing implementation / boundaries Reviewed against master `87c22dde7`. Matching currently lives in [AbstractShenyuPlugin](https://github.com/apache/shenyu/blob/87c22dde7/shenyu-plugin/shenyu-plugin-base/src/main/java/org/apache/shenyu/plugin/base/AbstractShenyuPlugin.java); execution ordering lives in [ShenyuWebHandler](https://github.com/apache/shenyu/blob/87c22dde7/shenyu-web/src/main/java/org/apache/shenyu/web/handler/ShenyuWebHandler.java). This is an explanation/simulation feature, separate from sending a real debug request through SandboxService, from request tracing, and from #6081's matching-engine refactoring. Existing matching fixes should remain independent prerequisites rather than being duplicated here. No runtime implementation or performance gain is claimed by this proposal. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
