Why
HttpFilter has no lifecycle for work that must outlive a request and die with the pipeline. Filter construction is synchronous and often runs with no Tokio runtime. Hot reload drops the old pipeline.
The workaround is a private OS thread plus a private current-thread runtime, cancelled in Drop. On main that exists in one filter: intelligent_route overlay reload. The next copy is already in flight (praxis-proxy/ai#815, Entra token refresh) for a timer and one HTTP POST — work that does not need a thread.
Without a pipeline-scoped place to run this work, every watch-or-refresh filter will mint another thread. Reload then leaks tasks and, for credential filters, secrets.
Server-owned loops (config watcher, health checks, TLS cert watcher) and Pingora BackgroundService are process/listener lifetime. They are not this problem.
Not this issue
- How to implement a supervisor
- Shipping Azure AD / Entra token refresh
Why
HttpFilterhas no lifecycle for work that must outlive a request and die with the pipeline. Filter construction is synchronous and often runs with no Tokio runtime. Hot reload drops the old pipeline.The workaround is a private OS thread plus a private current-thread runtime, cancelled in
Drop. Onmainthat exists in one filter:intelligent_routeoverlay reload. The next copy is already in flight (praxis-proxy/ai#815, Entra token refresh) for a timer and one HTTP POST — work that does not need a thread.Without a pipeline-scoped place to run this work, every watch-or-refresh filter will mint another thread. Reload then leaks tasks and, for credential filters, secrets.
Server-owned loops (config watcher, health checks, TLS cert watcher) and Pingora
BackgroundServiceare process/listener lifetime. They are not this problem.Not this issue