How to handle long-running asynchronous methods during a Meteor zero-downtime deployment

When using the meteor deploy command to update a small application, Meteor initializes the new version instance before terminating the old process. While the DDP protocol manages client-server synchronization, the behavior of active asynchronous tasks during this process swap remains a concern.

If a server is executing a long-running asynchronous method when the deployment triggers a shutdown, the abrupt termination of the old container may leave the task in a partially completed state. This is particularly problematic when the application relies on local-memory state that is not immediately synchronized with the MongoDB Oplog during the handover.

What mechanisms exist within Meteor to ensure these asynchronous operations complete or persist state before the old instance is killed? Are there built-in hooks to intercept the graceful shutdown signal to prevent data inconsistency during the transition?