FeathersJS Service Hooks and Transport Layer Cancellation: Propagating Socket.io Disconnect to Ongoing DB Query

Goal: Ensure that a Socket.io client disconnect triggers cancellation of any ongoing FeathersJS service method, such as a long-running database query, so that server resources are not wasted on abandoned requests.

Uncertainty: FeathersJS passes request information through the params object, but the framework does not automatically map a transport-layer disconnect to an AbortSignal or similar cancellation token that hooks can observe. While a custom before‑hook can start a timer or watch for a disconnect flag, it is unclear whether the signal can be reliably propagated to the service logic without modifying the client, and whether database drivers that lack native AbortSignal support can be made to honor the cancellation.

Specific questions:

• Can a transport-level disconnect be forwarded to a service hook as an AbortSignal without requiring changes to the Socket.io client?
• What pattern allows a long-running database operation to respect an abort signal when the underlying driver does not natively support it?
• Is there a recommended cleanup strategy for resources if the hook detects cancellation after the query has already begun?