[Silthus]

Problem

A workflow run whose push notification fails transiently after an email resumes at the wrong place: it leaves the email queue at the email priority instead of its own.

• The email worker stores the run's origin queue and priority in queueMetadata when it takes the email.
• A push retry on the email queue replaced that metadata with only its retry counter, so the origin was lost.
• The push retry also set the row's priority to its retry count, which ranks it among the email priority classes (transactional 0, bulk 1).
• A cross-model review of fix(workflows): keep queue and priority across email queue retries #112850 found this. It is on master today.

Note

Depends on #112850. The branch carries its commit, so review only the top commit (6febf8b). A native stack is not possible because #112850 comes from a fork.

Note

🔵 Merge risk: low · two-way door (merge-risk rubric)

• Thirteen production lines change the queue priority and metadata of a push retry while a run is on the email queue. Push sends, retry delays and the retry budget do not change.
• The round-trip test pins both fields, and a revert restores the old behavior. Rows already queued carry metadata that code on master already reads.

Changes

• A run that retries a push on the email queue now returns to its origin queue at its origin priority, like an email retry after fix(workflows): keep queue and priority across email queue retries #112850.
• The retry waits at its own message category's email-queue priority (transactional 0, everything else 1), the rule an inline email send already follows. The retry delay still spaces retries out, so the retry count does not need to set the order.
• Each push action keeps its own retry budget. The fix adds only the origin fields to the push service's result, after the send. The obvious fix copies the run's metadata onto the push before the send. That carries one push's retry count into the next push, because fix(workflows): keep queue and priority across email queue retries #112850 keeps the metadata between actions on the email queue.
• PushNotificationService does not change. Push retries off the email queue keep the retry-count priority.
• The sending-tiers doc gains one sentence on push retries.

How did you test this code?

Test rationale: extends the existing email round trip in hogflow-executor.service.test.ts, the only test that drives a run onto the email queue and back. No new standalone test.

• Test seam: HogFlowExecutorService.execute, through the queue, priority and metadata of each result.
• The run sends an email, then two transactional pushes that FCM rejects once each with a 503, then a throttled email, then a fetch.
• It asserts each push retry keeps originQueue: hogflow, originPriority: 2, tries: 1 at priority 0, and that the run returns to hogflow at priority 2.
• The test uses the real PushNotificationService, with only the FCM fetch stubbed.
• Before the fix, the run returned at priority 1 and each retry held only { tries: 1 }.
• With the naive pre-send copy in place of the fix, the test fails with tries: 2 on the second push and priorities 1 and 2.
• Ran locally: hogflow-executor.service.test.ts, push-notification.service.test.ts, hog-executor.service.test.ts and email.service.test.ts, all green.
• Not checked: a real FCM or APNs provider, or a deployed worker.

Release status

• No feature flag controls this change

Docs update

docs/internal/workflows-email-sending-tiers.md states that a push retry on the email queue restores the origin and uses its own category's priority.

🤖 Agent context

Autonomy: Human-driven (agent-assisted)

Agent: Claude Code, Claude Opus 5.5 (claude-opus-5-5)

• Split out of the fix(workflows): keep queue and priority across email queue retries #112850 rework as a separate fix. A Codex GPT 6.1 Sol review of fix(workflows): keep queue and priority across email queue retries #112850 reported the bug.
• Skills invoked: /tdd, /writing-tests, /stacking-prs, /pr, /writing-pr-descriptions, /merge-risk.
• Cross-model review: a Codex GPT 6.1 Sol adversarial review of the top commit reported no findings. It reran the suite and broke the fix three ways in memory: lost origin, retry-count priority, and tries leaking. The test failed each time.
• No duplicate: an open-PR search for push retries on the email queue found nothing.
• Public artifact: the test data is invented. No session material outside this repository is in the diff.

🤖 Generated with Claude Code

[trunk-io]

Merging to master in this repository is managed by Trunk.

• To merge this pull request, check the box to the left or comment /trunk merge below.

After your PR is submitted to the merge queue, this comment will be automatically updated with its status. If the PR fails, failure details will also be posted here