Trigger.dev 在 Windows WSL 环境下子任务执行问题解析

问题背景

Trigger.dev 是一个任务调度和自动化平台，开发者在使用过程中发现了一个特定环境下的执行问题。当在 Windows 系统的 WSL（Windows Subsystem for Linux）环境中运行 Trigger.dev 时，父任务可以正常执行，但子任务会一直停留在"queued"状态，最终因超时而失败。

环境特征

这个问题主要出现在以下环境配置中：

• 操作系统：Windows 10/11 搭配 WSL（Ubuntu 22.04）
• Node.js 版本：18.x 或 21.x
• 使用 Trigger.dev 的任务调度功能

问题表现

开发者定义了一个父子任务结构：

const parentTask = task({
  id: 'parent'
  run: async (payload) => {
    console.log(`Start parent`);
    await childTask.triggerAndWait({...});
  }
});

const childTask = task({
  id: 'child',
  run: async (payload) => {
    console.log(`Child task`);
  }
});

在这种配置下，父任务能够正常执行并打印日志，但子任务会卡在"queued"状态，不会执行也不会输出任何日志。

根本原因

经过社区验证，这个问题与模块导出机制有关。在 WSL 环境下，Trigger.dev 的任务调度系统需要明确的任务导出才能正确识别和执行子任务。

解决方案

解决这个问题的方法很简单：确保所有子任务都使用 export 关键字显式导出。

修正后的代码示例：

export const parentTask = task({
  id: 'parent'
  run: async (payload) => {
    console.log(`Start parent`);
    await childTask.triggerAndWait({...});
  }
});

export const childTask = task({
  id: 'child',
  run: async (payload) => {
    console.log(`Child task`);
  }
});

技术原理

在 WSL 环境下，模块系统对导出/导入的处理可能与原生 Linux 环境有些微差异。显式导出确保了：

1. 任务定义在模块作用域中正确注册
2. Trigger.dev 运行时能够发现并调度这些任务
3. 父子任务之间的依赖关系能够正确建立

最佳实践

为了避免类似问题，建议开发者：

1. 始终使用 export 导出所有任务定义
2. 在 WSL 环境下特别注意模块导出机制
3. 对于复杂的任务依赖关系，考虑使用单独的文件组织任务定义

总结

Windows WSL 环境下的模块导出机制可能导致 Trigger.dev 的子任务无法被正确识别和执行。通过显式导出所有任务定义，可以确保任务调度系统正常工作。这个问题虽然表现形式特定，但解决方案简单明了，体现了良好的模块化编程实践的重要性。