Stop the run-log flood from same-queue self-reschedules #43

Parent

Spec: #22 — Generate text, an LLM action node for workflows.

What to build

A workflow step that reschedules itself currently writes two run-log lines on every hop. Those lines are read by customers. A step that polls for a slow result would flood the run log a customer opens to understand their own workflow.

The suppression that exists today only applies when an action moves to a different queue and is not scheduled for later. A step that stays on its own queue and schedules itself a couple of seconds out satisfies neither half, so it takes the full resume-and-execute logging on every hop.

Widen the suppression so that a continuation of the same action on the same queue is also treated as routing noise and does not write customer-facing log lines.

Two existing cases must keep their log lines, because in both of them the reschedule is information the customer needs: a fetch being retried, and an SES send being throttled. Both of those also self-reschedule on an unchanged queue, so they sit squarely in the region being widened — the suppression has to tell a same-action continuation apart from them rather than silencing every same-queue reschedule.

This is a small change, and it is a hard precondition for the LLM node's polling transport (#22). It must land before or with that transport, never after.

Acceptance criteria

• A step that reschedules itself as a same-action, same-queue continuation writes no run-log lines for the hop.
• A fetch retry still writes its existing run-log lines, unchanged.
• An SES throttle still writes its existing run-log lines, unchanged.
• A test covers all three cases together, so a future widening cannot silence the two that must stay.
• No change to when a step is rescheduled, only to what it logs.

Blocked by

None — can start immediately.