[platform] Recurring automation ticks re-delivered 3-30x per batch to live sessions (cross-type, multi-day)
维护者通常 3 天内回复
还没有人认领这个 Issue。
评估
- 难度
- 4/5
- 预计耗时
- 3-5 天
- 新手友好度
- 38/100
- Issue 类型
- 缺陷
- 描述清晰度
- 基本清楚
- 活跃度
- 活跃
- 领域
- backend
调研方向
No repository file, test, or entry point is identified; start by locating the upstream message-dispatch and recurring-automation delivery path. Reproduce or inspect duplicate deliveries across automation types, then verify that each (automation_id, slot_ts) is delivered once or exposes a reliable idempotency signal, with telemetry if that is the chosen resolution.
由索引模型根据 Issue 内容生成。
描述
Summary
Recurring automations (cron-style scheduled prompts) are being re-delivered to live sessions multiple times per tick. Observed continuously across several days (2026-09-16 → 09-25):
- Same tick / same minute delivered 3–30× per batch, batch-internal gaps of 8–20 seconds;
- A single inbound message can contain 30+ verbatim copies of the same scheduled instruction;
- Affects multiple sessions and multiple automation definitions; also observed for non-heartbeat message types (a whole advisory report got re-delivered the same way), so it is not specific to one automation's content.
Local-side forensics (all clean)
crontab -l: no related entries;launchctl: the automation runs as a single launchd instance (no duplicate daemons);- The scheduled script itself is deterministic and idempotent — every delivery logs
ok=true, repeated ticks short-circuit as already-done.
⇒ The duplication is not produced on the local machine. Root cause appears to be concurrent dispatch in the upstream delivery layer (multiple host-side workers picking up the same scheduled slot).
Impact
- Massive token/context waste: the vast majority of session messages become heartbeat noise;
- Statistics corruption: any acceptance/coverage metric counted from tick delivery must de-duplicate by timestamp (same tick ≥5 min apart counts once) — raw counts are unusable;
- Cross-type spread (advisory reports re-delivered verbatim) suggests the duplication happens at the message-dispatch boundary, not in automation definitions.
Requests
- Upstream delivery layer should de-duplicate per
(automation_id, slot_ts)— deliver once per slot, or coalesce concurrent workers; - Or expose an idempotency key / delivery contract so clients can reliably detect re-delivery;
- Or at minimum, expose per-automation duplicate-delivery telemetry so affected users can confirm the diagnosis.
Happy to provide sanitized timestamp logs if useful.
- 主要语言
- Python
- 星标
- 73
- 派生
- 46
- PR 合并指标
- 30 天内没有已合并 PR
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
zai-org/zcode-plugins 的其他 Issue
-
难度 2/5 1-3 小时 新手友好度 85/100
zai-org/zcode-plugins#14 ·
维护者通常 3 天内回复
-
请开放新的渠道未关闭
难度 5/5 一周以上 新手友好度 20/100
zai-org/zcode-plugins#48 ·
维护者通常 3 天内回复
-
难度 5/5 一周以上 新手友好度 45/100
zai-org/zcode-plugins#43 · 2 条评论 ·
维护者通常 3 天内回复
-
难度 4/5 3-5 天 新手友好度 40/100
zai-org/zcode-plugins#41 ·
维护者通常 3 天内回复
-
难度 4/5 3-5 天 新手友好度 40/100
zai-org/zcode-plugins#37 ·
维护者通常 3 天内回复
查看 zai-org/zcode-plugins 的全部 Issue
相似的 Issue
-
needs triage
难度 2/5 1-3 小时 新手友好度 78/100
维护者通常 2 天内回复
-
难度 2/5 1-3 小时 新手友好度 82/100
openvinotoolkit/openvino_notebooks#3665 ·
维护者通常 1 天内回复
-
bug
难度 2/5 1-3 小时 新手友好度 86/100
维护者通常 1 天内回复
-
docs
难度 2/5 1-3 小时 新手友好度 88/100
维护者通常 1 天内回复
-
benchmark-gap
难度 2/5 1-3 小时 新手友好度 78/100
维护者通常 1 天内回复