[Bug] 已完成的任务仍无条件等待 1–4 分钟

任务没有待执行项目时，活动函数会提示“所有项目已完成”并立即返回，但主流程仍会等待 1–4 分钟才进入下一阶段，导致重复运行时，已完成的任务也持续占用时间。

复现时，启用 workers.doMorePromotions，将模拟仪表板中的 morePromotions 和 morePromotionsWithoutPromotionalItems 设为空数组，或将其中的项目全部标记为 complete: true，然后执行对应阶段。MorePromotions.run() 会直接返回，不调用活动执行器；观察上层流程，仍可看到一次 60000–240000 毫秒的等待调用。

原因在于，空任务分支提前返回后，主流程仍无条件调用 gapBetweenWorkers()，而等待函数固定生成 1–4 分钟的随机间隔，没有区分阶段是实际执行了活动，还是因全部完成而跳过。

已有日志中，“更多推广”在 09:20:10 提示全部完成，下一阶段签到直到 09:23:33 才开始，相隔 3 分 23 秒。多个已完成阶段会分别累加等待，而等待信息只记录在 DEBUG 日志中，普通日志下容易看起来像程序停滞。

预期没有待执行项目的阶段直接跳过，实际执行活动后的等待保持原有逻辑。

补充实际运行记录和代码依据。版本为 V4-china v4.3.2.4，对应提交 e0c15a6。

2026-10-24 的运行日志（UTC+8）中，两类任务提示全部完成后，到下一阶段开始分别相隔 3 分 23 秒和 3 分钟：

09:20:10 [MORE-PROMOTIONS] 所有"更多推广"项目已完成
09:23:33 [DAILY-CHECK-IN] 开始每日签到

09:26:41 [APP-PROMOTIONS] 所有"应用推广"项目已完成
09:29:41 [PUNCHCARD] 发现 1 个未完成任务

MorePromotions.ts 第 18–25 行在 pending.length === 0 时直接返回，后面的活动执行器不会被调用，但 index.ts 第 1007–1009 行仍继续等待：

if (this.config.workers.doMorePromotions) {
    await this.activities.doMorePromotions(data)
    await this.gapBetweenWorkers()
}

gapBetweenWorkers() 第 658–662 行每次都会生成 60000–240000 毫秒的随机等待；调用方只判断任务开关，没有判断这个阶段是否实际执行了活动。fullApi 分支第 975–977 行也有相同调用结构。

按这段代码计算，连续 5 个无待执行项目的阶段会额外等待 5–20 分钟，平均约 12.5 分钟。等待信息只写入 DEBUG 日志，普通 INFO 日志在提示“全部完成”后会长时间没有进展，既拖延后续阶段，也容易让使用者误以为程序卡住。

fix: 按打卡子项实际提交状态跳过空执行等待并补齐边界测试（chiihero#59）

style: 统一格式以满足 Issue #59 的全量 Prettier 检查

fix: 按任务执行状态跳过空阶段等待，保留原有等待时序并补齐回归测试（#59）

这个 #60 已经修了（阶段级 + 打卡子项 + 推广子项三层判断，空任务不再白等），已合并进 V4-china，感谢报告 🙏

Navigation Menu

Repository navigation

[Bug] 已完成的任务仍无条件等待 1–4 分钟 #59

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

[Bug] 已完成的任务仍无条件等待 1–4 分钟 #59

Description

Activity

GoldenSection0618 commented on Oct 24, 2026

chiihero commented on Nov 2, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions