Skip to content

fix(export): bound GenerateShort's wait for the short service - #447

Open
KillerX wants to merge 1 commit into
refactor/remove-dynamic-trigger-formfrom
fix/generate-short-bounded-polling
Open

fix(export): bound GenerateShort's wait for the short service#447
KillerX wants to merge 1 commit into
refactor/remove-dynamic-trigger-formfrom
fix/generate-short-bounded-polling

Conversation

@KillerX

@KillerX KillerX commented Aug 13, 2026

Copy link
Copy Markdown
Member

8/n of a stack. Base: refactor/remove-dynamic-trigger-form (#446). First of the Unbounded workflow histories findings.

The status loop had no exit but the job finishing. Each pass costs an activity and a timer — five history events — and it polled every five seconds, so a job stuck in in_progress wrote roughly 3,600 events an hour until the server terminated the execution for exceeding its history limit. The failure that reached the operator said nothing about the job.

Extracted as waitForShortJob: five seconds for the first two minutes, thirty after that, and it gives up at two hours with a non-retryable error naming the job. A stuck job now costs a few hundred events instead of tens of thousands, and a quick job is still noticed within five seconds. Two hours matches the ceiling the vizualizer wait already uses.

The extraction is also what makes it testable — three tests drive the loop through the test environment's clock, including the stuck-job case, which is not reachable while the loop is inline in a workflow that first has to get through export data, scene detection and a child workflow.

🤖 Generated with Claude Code

The status loop had no exit but the job finishing. Each pass costs an activity
and a timer — five history events — and it polled every five seconds, so a job
stuck in in_progress wrote roughly 3,600 events an hour until the server
terminated the execution for exceeding its history limit. The failure that
reached the operator said nothing about the job.

Extracted as waitForShortJob, which polls every five seconds for the first two
minutes and every thirty after that, and gives up at two hours with a
non-retryable error naming the job. A stuck job now costs a few hundred events
instead of tens of thousands, and a quick job is still noticed within five
seconds.

Two hours matches the ceiling the vizualizer wait already uses. Nothing about
the short service suggests a legitimate job runs longer; if one does, the
error says so rather than the execution disappearing.

The extraction is also what makes it testable: three tests drive the loop
through the test environment's clock, including the stuck-job case, which is
not reachable while the loop is inline in a workflow that first has to get
through export data, scene detection and a child workflow.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant