Expired JWTs keep Feathers websocket connections alive past authentication expiry

After a Feathers websocket handshake completes, the authentication plugin populates params.user and params.authenticated for subsequent service calls without re-validating the JWT on every message. Because the token is not re-checked per event, an expired or revoked JWT does not automatically disconnect the client; the socket remains in channels and continues consuming resources until the transport closes it.

The framework does not provide a built-in configuration or hook to force disconnection on token expiry, leaving cleanup as an application-level decision. This behavior may differ between Feathers major versions and between Socket.io and Primus transports, so the exact disconnect mechanism depends on the installed setup.

When diagnosing intermittent resource exhaustion, it is unclear whether the issue stems from these lingering authenticated sockets or from separate database adapter pool limits, since Feathers core exposes no unified connection-pool metrics.

Is there a documented pattern for detecting expired JWTs on active websocket connections and removing them from channels without manually closing the socket? Which Feathers version and transport combinations support per-call token verification, and where is that behavior configured? How can applications distinguish between transport-level socket exhaustion and database adapter pool exhaustion when Feathers provides no unified metrics?