[bug] 2-4 "PAGS is live" notifications per push — the deploy watcher polls every workflow and calls a green CI run a deploy

[serge-ivo]

Reported symptom

"why do I get so many notifications that PAGS is live?"

That string is lib/deploy-watch.ts:90 — `${repoName} is live.` — the body of the ✅ deploy
notification. The user is getting several per push, and some ❌ failure notifications for builds that
did not fail.

Cause: the watcher asks GitHub for "the newest run" and this repo has seven workflows

runDeployWatch polls one endpoint per repo (lib/deploy-watch.ts:133):

const res = await fetchWorkflowRuns(repo.github_repo, token, { perPage: 1 });
const raw  = "runs" in res ? res.runs[0] : undefined;

and fetchWorkflowRuns (lib/github-actions.ts:28-44) builds its query from per_page and page
only:

const qs = `per_page=${perPage}${page > 1 ? `&page=${page}` : ""}`;
fetch(`https://github.com/ghapi/repos/${repo}/actions/runs?${qs}`)

No workflow_id, no branch, no event, no status. So runs[0] is the newest run across every
workflow in the repo. ProAgentStore/platform has seven:

ci.yml  deploy-api.yml  deploy-host.yml  deploy-mcp.yml
deploy-testflight.yml  publish-mcp-registry.yml  publish-npm.yml

One push to main starts two to four of them. They finish at different times, so the per-minute cron
sees a different newest run id on successive sweeps, and decideDeployNotification fires on each
one — its only dedup is lastNotifiedRunId === run.id (:79), a single watermark column
(coding_repos.last_deploy_run_id) against an interleaved stream of runs from unrelated workflows.
It can never settle.

Real runs from this repo, same push, two workflows each:

b1266cf  CI              success
b1266cf  Deploy API Wor…  success
31e41cc  CI              success
31e41cc  Deploy Host Wo…  success

≈2–4 notifications per push. The session before this filed ~20 pushes in three hours.

Three separate wrongnesses, not one

1. CI is not a deploy. A green ci.yml run produces "✅ Deployed #412 — PAGS is live." Nothing
was deployed and nothing went live; typecheck passed. This is the notification claiming an outcome it
has no evidence for — the same honesty rule the platform applies to agents.

2. A cancelled run reports as a build failure. ok = run.conclusion === "success" (:84), so
anything else takes the ❌ branch: "❌ Build failed #N — PAGS — cancelled." Superseded runs are
cancelled routinely by concurrency groups (there are two in the recent list), so pushing twice in
quick succession sends a failure alarm for a build that was merely replaced.

3. The run number is per-workflow. #412 from CI and #88 from Deploy API arrive minutes apart
for the same commit, so the number carries no usable meaning across notifications.

No dedup anywhere downstream

notifyUser (routes/push.ts:196-206) does two things with no coalescing, no rate limit and no
recent-duplicate check:

• createNotification(...) — the in-app list keeps every copy;
• sendPushToUser(..., { tag: type }) — tag is the literal string "deploy", so the OS tray
  visually collapses them to one, but each still fires its alert. That is why it feels like far more
  notifications than the tray shows: the buzzes are real, the tray is lying by collapsing them.

Fix

The root error is treating any completed workflow run as a deploy that put something live. The
watcher needs to know which workflow is the deploy, and only speak for that one.

Options, in rough order of preference:

1. Filter the query. fetchWorkflowRuns should accept branch, event and status, and the
   watcher should pass the repo's default branch, event=push, status=completed. That alone kills
   the PR/branch noise and the in-progress churn, but not the CI-vs-deploy confusion, because CI
   also runs on push to main.
2. Name the deploy workflow. Either let a coding_repos row declare it, or default to matching
   the workflow file/name against a deploy pattern, and query .../actions/workflows/<id>/runs. This
   is what actually fixes it — one workflow, one watermark, one notification.
3. If more than one workflow legitimately deploys (this repo deploys api, host and mcp
   separately), the watermark has to become per (repo, workflow) rather than the single
   last_deploy_run_id column, and the body should name which one — "api Worker is live", not
   "PAGS is live".

Whatever is chosen, conclusion === "cancelled" should be silent, not a failure alarm.

Worth considering alongside

notifyUser has no duplicate suppression at all, and this is the second notification bug in the same
area (#338, #344, #349 were all deploy/handoff notification defects). A cheap floor — drop an
identical (user, type, title, body) inside some short window — would have bounded this one to a single
buzz instead of eighty, regardless of the watcher's logic.

[serge-ivo]

The duplicate-suppression note in the closing section is split out as #361 so it is not lost when this closes, and #360 covers the user-facing controls (per-type mute, actor suppression) that would have let you turn this class off while it was misbehaving.

Three layers, three jobs — fix all three, none substitutes for another:

• this — the caller bug: the watcher polls every workflow and calls a green CI run a deploy.
• [bug] notifyUser has no duplicate suppression — the push tag hides the repetition in the tray while every alert still fires #361 — the floor: nothing between a malfunctioning caller and the device says "I already sent this."
• Notifications have no per-type mute and no notion of "you caused this" — #176's visibility gate cannot cover your other devices #360 — the control: push is all-or-nothing today, so muting deploys also loses the CAPTCHA handoff.

[serge-ivo]

Fixed in 3376aba, with the floor from #361 (5641598) underneath it.

The event is a commit's deploy, not a workflow run. That is the correction the three
wrongnesses all reduce to. The old watermark was a single run id compared against "the newest run
in the repo"; no dedup on a run id could ever settle against an interleaved stream from seven
workflows, because the run id was never the thing the user cares about. They pushed once, so they
are told once: runs are grouped by head_sha, the watermark is the commit, and one notification
names every deploy workflow that built it — "acme/app is live — Deploy API Worker, Deploy Host
Worker."

Against the three items in the issue:

1. Filter the query. Done — fetchWorkflowRuns takes branch/event/status; the sweep asks
   for event=push, status=completed, per_page=20. Existing console/connector callers
   unchanged.
2. CI is not a deploy. isDeployWorkflow matches the workflow file first (deploy-api.yml,
   deploy.yml — what the scaffolded agent repos use) and its display name second. A repo whose
   deploy workflow is named something else now gets silence rather than a lie; declaring the
   workflow on coding_repos is the escape hatch to add when a real repo needs it. Took the
   pattern default rather than a per-workflow query, because option 3 already had to happen:
3. More than one workflow legitimately deploys. Rather than a per-(repo, workflow) watermark —
   which would have made this repo send three notifications per push instead of four — the
   watermark is the commit and the body names the parts. Same information, one interruption.

cancelled is now silent and does not burn the watermark, so the commit is still reported when
a real deploy for it concludes. skipped/neutral/stale/null likewise. The evidence is in
this repo's own history — of the last 12 Deploy API Worker runs, 5 are cancelled by the
concurrency group, and each of those used to send "❌ Build failed — cancelled."

The per-workflow run number is gone from the title in favour of the short sha, which means the same
thing across every notification and is the string you already read in git log.

Upgrade: the watermark column keeps its legacy name (last_deploy_run_id) and now holds
sha:<commit>. A value in the old format can never equal a sha, so it reads as first sight and
is re-seeded silently — one quiet sweep per repo, and no announcement of a build that already went
out.

The notification also declares its event key to #361's floor, so a future watermark bug can only
buzz once per window rather than once per sweep. Belt and braces on purpose: this was the fourth
defect in this area.

[serge-ivo]

Fifth defect in this area, filed as #708 — and the finding is that this ticket's fix is intact, not
regressed. The event is still the commit, CI is still not a deploy, cancelled is still silent.

What #708 adds: decideDeployNotification compares the commit for equality
(lib/deploy-watch.ts:156-158) and runDeployWatch persists whatever it computed
(lib/deploy-watch.ts:288-292), so an occasional stale GitHub runs page — reproduced live today, 1 of
30 identical requests to the sweep's exact URL returned a snapshot 3½ weeks old — makes the watcher
announce an old commit and roll the watermark back to it. The next correct read then differs and
fires again. One bad read = two buzzes, repeatable forever. Measured: 198 deploy rows for 32 real
deploys over 52h, freeappstore-online/platform alternating between a 2026-07-31 commit and a
2026-08-14 commit 41 times each while nobody pushed to it.