nest-boot-queue
Installation
SKILL.md
先确认版本与职责
读取宿主 manifest、锁文件和实际公开类型。本文针对 @nest-boot/queue 8.2+、@nest-boot/queue-api 8.1+。运行时是 Node.js >=24.21.0、NestJS 12、原生 ESM；当前 BullMQ peer 是 ^6.3.12。
@nest-boot/queue只负责 Redis 执行，不依赖数据库、GraphQL 或数据库迁移。@nest-boot/queue-api可选，负责数据库 Job 历史、认证和 GraphQL 查询；不承担 Redis 状态存储。- 先确定生产者、消费者及历史/API 各在哪个进程运行，再配置模块与启动入口。
核心规则
- 声明队列 provider。 用
@Queue(name?)装饰继承BaseQueue的 class；静态名称在装饰器中，Redis/defaultJobOptions 在super(options)中。@Queue()会去掉类名末尾的 Queue 后转 kebab-case。 - 以 schema 为任务契约源。 声明具体的
readonly jobSchemas，每个任务的data必须是z.object()；result可省略，省略意味着 handler 返回Promise<void>。保留对象字面量推导，不把属性显式拓宽为JobSchemas。 - 每个任务一个 handler。 使用
@Processor(QueueClass)、BaseProcessor和Job<QueueClass, 'job-name'>；send-email对应processSendEmail。参数与返回类型都要匹配，转换后重名的任务会被拒绝。 - 直接注入队列 class。 Queue 与 Processor 都是 singleton providers，放入所属模块的
providers。Processor 类名前缀与 Queue 一致由共享 ESLint 规则检查，不是 TypeScript 自动比较类名。 - 显式启动消费。 注册队列会启动 QueueEvents，注册 Processor 不自动启动 Worker。通过
QueueManager.start(names?)或queue:start消费；不传过滤器启动全部，传入名称仅启动所选队列。 - 验证保留原值。 add/addBulk、调度模板、消费和完成结果使用异步 Zod 校验，但丢弃解析结果，类型采用
z.input。不承诺默认值、strip、coerce、transform 会改写 Redis payload 或 handler result；优先声明稳定、可 JSON 序列化的契约。解释校验边界时同时说明：原生job.updateData()不经过封装校验，消费时仍会复验；addBulk 在写入前先验证整个批次。 - 分开上下文与身份。 每个 job 有自己的 RequestContext，singleton Processor 不保存当前 job 或临时路径。原 HTTP 的 user/workspace/member 不自动传播，业务授权仍要从可信标识重新建立。