[Silthus]

Problem

• Workflow runs that retry an email or push on the email queue return to hogflow at the wrong priority, so bulk sends can jump ahead of other work.

Changes

• These runs now return to their origin queue at their original priority.
• Email reschedules and the executor keep the stored origin.
• A push retry restores the origin after the send.
• The executor drops the team cap flag before later actions, so only the delayed email counts as a cap delay.
• Mechanical: a priority helper and the doc.

Before:

flowchart LR
  A[run on hogflow, priority 2] --> B[email queue]
  B --> C[email or push retry]
  C --> D[hogflow, priority 0 or try count]
  classDef phYellow fill:#f9bd2b,stroke:#f9bd2b,color:#000;
  classDef phRed fill:#f54e00,stroke:#f54e00,color:#fff;
  classDef phBlue fill:#1d4aff,stroke:#1d4aff,color:#fff;
  class A phYellow;
  class B,C phBlue;
  class D phRed;

Loading

After:

flowchart LR
  A[run on hogflow, priority 2] --> B[email queue]
  B --> C[email or push retry]
  C --> D[hogflow, priority 2]
  classDef phYellow fill:#f9bd2b,stroke:#f9bd2b,color:#000;
  classDef phBlue fill:#1d4aff,stroke:#1d4aff,color:#fff;
  class A,D phYellow;
  class B,C phBlue;

Loading

Note

During the rollout, a run an old worker rescheduled finishes at the old priority, without errors.

How did you test this code?

Test rationale: existing tests now fail without each production line.

• Email tests, the executor round trip and a cap test pin the origin and the cap flag.
• A local live run with fake SES and FCM gave the table below.
• Base and head workers finished each other's jobs, both ways.
• Not checked: real providers, degraded flows, or live workflow pacing.

Live run: priority on return to hogflow (origin priority 1)

Scenario	Base 03cb9b8	Head 0d1bb84
SES throttle reschedule	0	1
Two push retries	2	1
Both	2	1
Team cap delay, then a second email	Not run	1

All runs completed. Each value comes from a cyclotron_jobs snapshot taken as the run left the email queue. In the cap run, only the delayed send recorded team_capped="true".

Release status

• No feature flag controls this change

Docs update

• The sending-tiers doc covers retries.

🤖 Agent context

Autonomy: Human-driven (agent-assisted)

Agent: T3 Code / Claude Code, Claude Opus 5.5. An earlier version: Codex, GPT-6.1 Sol.

Skills: /tdd, /writing-tests, /writing-pr-descriptions, /recreating-fork-prs, qa-swarm, merge-risk

More context for AI agents

• Session: T3 Code thread, Claude Code.
• Decisions: recreated from fork PR fix(workflows): keep queue and priority across email queue retries #112850, which could not run CI from the fork, at its pinned head 29d303f; all commits are by the PR author, so no squash.
• Decisions: fda06d5 passes the two PushNotificationService arguments master added, in the executor test only.
• Decisions: 0d1bb84 follows a master merge that added the team sending cap's teamCapped flag (feat(cdp): label email queue waits that the team sending cap delayed #126304). The merge keeps master's cap reschedule line in the email service, and the executor drops the flag for later actions.
• Decisions: the push fix first opened as fix(workflows): keep email origin when a push retries on email queue #115192 and folded in here, because it needs the executor line.
• Decisions: a QA swarm ran two rounds on the fork PR across GPT-6.1 Sol and Claude Opus 5.5; findings are fixed. Three GPT-6.1 Sol reviews on this PR found nothing.
• Follow-ups: the cloneInvocation comment does not match its code; pre-existing.
• Read closely: keepPushRetryInEmailQueueOrder, the executor's queueMetadata line, and withoutTeamCapped.
• No duplicate: no other open PR carries this fix.

🤖 Generated with Claude Code

[trunk-io]

😎 Merged successfully - details.

[github-actions]

🤖 CI report

✅ Trunk lane — non-backend lane

This PR is assigned to the non-backend lane. It does not run backend Python tests and may merge in parallel with PRs in other lanes.

✅ Duplication (Python) — clean

New Python code duplication introduced by this branch. Fails at 70+ tokens in app code, or 150+ tokens when both copies live in test files. Advisory while the gate proves itself: extract a shared helper instead of copying.

✅ Duplication (TypeScript) — clean

New TypeScript code duplication introduced by this branch. Fails at 70+ tokens in app code, or 150+ tokens when both copies live in test files. Advisory while the gate proves itself: extract a shared helper instead of copying.

[posthog]

PostHog Review · Standard · reviewed 29d303f: 1 Must fix.

This is the only automatic review while this pull request is a draft. Comment @posthog review to review new changes sooner. Otherwise, a review of the new changes runs when you mark it ready for review.

See this review and its findings in PostHog Review. Comment @posthog review --deep for a Deep review. A Deep review takes longer and looks deeper than a Standard review.

[hosthog]

HostHog preview — posthog-desktop-web

The previews for this PR have been torn down and no longer serve.

[parameterai]

Risk: No findings

This increment is a master merge bringing the UTM link-scanner rollout into the branch, plus the PR's wiring of the team gate in email.service.ts. The gate is fail-closed (empty or malformed config falls back to the unchanged legacy scanner), the new scanner's href rewrite only appends fully URL-encoded parameters and re-escapes the attribute value, and the merge resolution dropped nothing from master. No new security issues found.

_{Sentinel reviewed 2ba5e33 · Review settings}

[pr-assigner-resolver-posthog]

👀 Auto-assigned reviewers

These soft owners were skipped because they only have minor changes here. Nothing blocks merge, so self-assign if you'd like a look:

• @PostHog/team-ingestion (owners.yaml)

Soft owners come from each directory's owners.yaml and each product's product.yaml (resolved nearest-file-wins). For a skipped owner, the locator is the file that decided it. Generated files and lockfiles are ignored when deciding ownership.

[Silthus]

/trunk merge

[Silthus]

/trunk merge

[deployment-status-posthog]

Deploy status

Environment	Status	Deployed At	Workflow
dev	✅ Deployed	2026-11-03 22:15 UTC	Run
prod-us	✅ Deployed	2026-11-03 22:48 UTC	Run
prod-eu	✅ Deployed	2026-11-03 22:37 UTC	Run