Vapor请求上下文内创建的Timer及DispatchQueue延迟任务不触发问题

问题根因 #

不存在Vapor框架本身的已知bug，该问题是服务端与客户端的运行环境差异导致的：

• Timer依赖活跃RunLoop才能运行：iOS/macOS客户端主线程默认启动常驻RunLoop，会自动把调用scheduledTimer创建的定时器加入循环执行。但Vapor基于SwiftNIO的EventLoop线程模型，除了核心网络事件循环外，普通线程的RunLoop不会持续运行，你创建的Timer没有被加入活跃RunLoop，离开当前作用域后就会被释放，永远不会触发。
• DispatchQueue.main在服务端场景无效：服务端没有UI主循环的概念，主队列的调度逻辑和客户端完全不同，部分Linux部署环境下甚至会直接丢弃主队列的延迟任务。
• 你在请求回调中创建的定时器/延迟任务没有被全局持有，请求处理完成返回响应后，临时作用域被销毁，未执行的任务会被直接回收。

解决方案 #

场景1：短时间延迟、服务重启后任务丢失可接受 #

直接使用Vapor EventLoop自带的调度能力，同时全局持有调度任务的引用避免被回收：

1. 首先在你的Tournament类中添加全局持有容器：

extension Tournament {
    // 用赛事ID作为键持有待执行的任务
    static var pendingTimers: [UUID: EventLoopScheduledTask<Void>] = [:]
}

2. 修改定时器添加方法，传入当前请求关联的EventLoop：

static func addTournamentTimer(_ tourn : Tournament, on eventLoop: EventLoop) {
    // 调度5分钟后执行的任务
    let task = eventLoop.scheduleTask(deadline: .now() + .minutes(5)) {
        print("Timer fired for tournament \(tourn.name)")
        // 执行完成后移除引用释放内存
        Self.pendingTimers.removeValue(forKey: tourn.id!)
        // 此处添加你要执行的业务逻辑
    }
    // 全局持有任务
    Self.pendingTimers[tourn.id!] = task
    print("adding timer for tournament \(tourn.name)")
}

3. 调用时传入请求的EventLoop即可：

Tournament.addTournamentTimer(tourn!, on: req.eventLoop)

场景2：生产环境、长时间延迟、服务重启不能丢失任务 #

使用Vapor官方的Queues组件，把任务持久化到Redis或数据库中，由任务队列统一调度执行，这是服务端延迟任务的标准实现方案。

注意事项 #

不要在Vapor服务端代码中使用iOS/macOS客户端常用的Timer、DispatchQueue.main.asyncAfter等API，所有异步调度逻辑都要走Vapor自带的EventLoop或官方生态组件实现。

内容的提问来源于stack exchange，提问作者Dan Donaldson