Repository navigation
The "Trigger fires" card counts 2 rows per cron fire and 3 per webhook fire, because dispatchTrigger writes a 'running' row the caveat never mentions #663
Description
The triggers.fires stats card counts 2 rows per cron fire and 3 per webhook fire, and its caveat names a different reason
Found in the D1 sweep prompted by #438.
Verified — every dispatch writes a running row plus a terminal row
workers/api/src/lib/triggers.ts:296-320, dispatchTrigger:
await recordTriggerEvent(env, trigger, sourceType, "running", { payload }); // :300
…
const eventId = await recordTriggerEvent(env, trigger, sourceType, "succeeded", { // :309
…
await recordTriggerEvent(env, trigger, sourceType, "failed", { payload, error: message }); // :320And the inbound webhook route writes a third before dispatching — workers/api/src/routes/triggers.ts:408-411:
await recordTriggerEvent(c.env, trigger, "webhook", "received");
…
await dispatchTrigger(c.env, trigger, "webhook", payload);Verified — the card counts rows
workers/api/src/lib/stats-sources.ts:359-366:
SELECT COUNT(*) AS v FROM agent_trigger_events
WHERE instance_id = ?1 AND user_id = ?2 AND created_at >= ?3 AND created_at < ?4wired as both the scalar and the daily rollup value (lib/stats-sources.ts:247 and :258).
Verified — the caveat names retries and failures, not the running row
workers/api/src/lib/stats-schema.ts:209-213:
id: "triggers.fires",
label: "Trigger fires",
kinds: ["number", "line", "bar", "table"],
describes: "Webhook and cron trigger events, grouped by status for bar/table.",
caveat: "Counts trigger EVENTS, which includes retries and failures — it is not a count of successful work.",A reader who accepts that caveat still expects one row per attempt. Neither the label nor the caveat says every attempt contributes a running row too.
User-visible impact
A "Trigger fires" card reads 2× reality for cron and 3× for webhook, constantly. The bar / table kinds group by status (lib/stats-sources.ts:251-253) so the parts do at least sum to the whole and a careful reader can recover the truth; the number and line kinds — the two a user glances at — have no breakdown and overstate by a fixed factor with nothing on the page to divide by.
Not claimed
Nothing inferred; all four write sites and the count query are quoted.
Refs #438.
Activity
serge-ivo commentedon Aug 18, 2026
Audit — still LIVE. Two citations drifted; the claims all hold.
Re-read every quoted line against
maintoday.Corrected coordinates —
0cd0bfc4(#649) andb5536ec4(#665) both editedroutes/triggers.ts, pushing the webhook write ~100 lines down:routes/triggers.ts:408-411:509await recordTriggerEvent(c.env, trigger, "webhook", "received");— line 408 today is cron re-anchoring, unrelatedlib/triggers.ts:296-320:303/:312/:333running/succeeded/failedwrites;:333is now outside the quoted rangelib/stats-sources.ts:359-366:362-369COUNT(*)scalar, unchangedlib/stats-schema.ts:209-213Still true, verified:
dispatchTriggerwrites arunningrow atlib/triggers.ts:303before doing anything, then a terminal row; the inbound webhook route writes a third atroutes/triggers.ts:509; the card counts rows with no status predicate (stats-sources.ts:362-369fornumber/line,:254-256grouped forbar/table); and the caveat still names only retries and failures.So the arithmetic in the title is unchanged: 2 rows per cron fire, 3 per webhook fire, on the two kinds a user glances at.
Leaving open, labels unchanged.
serge-ivo commentedon Aug 29, 2026
Fixed in commit a8c0faa. The
triggerFiresscalar/daily query and the bar/table grouped query now both filter withAND status NOT IN ('running', 'received'), so only terminal rows (succeeded + failed) are counted. One cron fire → 1; one webhook fire → 1. Three tests added tostats-sources.test.tsthat inspect the generated SQL to confirm the filter lives in the query. Caveat updated to describe what is counted.