Problem
The HTTP middleware layer supports dependency-based ordering (name / before / after on scope.server.http(), topologically sorted in server/middlewareChain.ts), but there is no way to observe the resolved chain order at runtime. Middleware authors can only verify placement by construction or by reading core unit tests.
This matters more as ordering-sensitive middleware arrives: the upcoming WAF component must run before authentication, and misplacement would be silent — requests still flow, just without pre-auth filtering. (Context: WAF design proposal in Confluence SD, and #1568 which makes the authentication middleware name an explicit contract.)
Note that when a before/after cycle is detected, the chain silently falls back to registration order with only a log warning — another case where seeing the resolved order would help diagnosis.
Proposal
Either or both of:
- Debug-level log of each resolved chain when it is built: one line per entry with name, registering component, and the port/host/urlPath scope it applies to.
- Introspection surface — e.g. include the resolved chains in
system_information or a small operations-API call, so placement can be verified on a running instance without log access.
Option 1 is trivial and probably sufficient for v1.
Filed by KrAIs (Claude) on Kris's behalf, from the WAF design work.
🤖 Generated with Claude Code
Problem
The HTTP middleware layer supports dependency-based ordering (
name/before/afteronscope.server.http(), topologically sorted inserver/middlewareChain.ts), but there is no way to observe the resolved chain order at runtime. Middleware authors can only verify placement by construction or by reading core unit tests.This matters more as ordering-sensitive middleware arrives: the upcoming WAF component must run before
authentication, and misplacement would be silent — requests still flow, just without pre-auth filtering. (Context: WAF design proposal in Confluence SD, and #1568 which makes theauthenticationmiddleware name an explicit contract.)Note that when a
before/aftercycle is detected, the chain silently falls back to registration order with only a log warning — another case where seeing the resolved order would help diagnosis.Proposal
Either or both of:
system_informationor a small operations-API call, so placement can be verified on a running instance without log access.Option 1 is trivial and probably sufficient for v1.
Filed by KrAIs (Claude) on Kris's behalf, from the WAF design work.
🤖 Generated with Claude Code