Hacktoberfest 2026:メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

[platform] Recurring automation ticks re-delivered 3-30x per batch to live sessions (cross-type, multi-day)

オープン
#44 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 3 日以内に返信

まだ誰も着手していません。

評価

難易度
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

  1. Massive token/context waste: the vast majority of session messages become heartbeat noise;
  2. 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;
  3. Cross-type spread (advisory reports re-delivered verbatim) suggests the duplication happens at the message-dispatch boundary, not in automation definitions.

Requests

  1. Upstream delivery layer should de-duplicate per (automation_id, slot_ts) — deliver once per slot, or coalesce concurrent workers;
  2. Or expose an idempotency key / delivery contract so clients can reliably detect re-delivery;
  3. 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
スター
39
フォーク
20
PR マージ指標
30日以内にマージされた PR はありません

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

zai-org/zcode-plugins のほかの issue

zai-org/zcode-plugins の issue をすべて見る

似ている issue

Python の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。