fix: the remaining Unbounded workflow histories sub-items

[KillerX]

10/n of a stack. Base: fix/incremental-ingest-signal-selector (#448). One commit per sub-item — the last three of the Unbounded workflow histories finding, after the two loops in #447 and #448.

MoveFilesWorkerFlow continues as new — 909ef4d

The finding calls it an eternal fixed-ID signal workflow whose history is never reset. It is not eternal: ReceiveWithTimeout gives up after ten seconds and the run completes, restarted by the next SignalWithStartWorkflow.

The real exposure is narrower. Requests arriving less than ten seconds apart keep one run alive indefinitely, and every move adds a GetShapes plus one MoveFileWait per shape to the same history — a bulk move never lets the run end. It now continues as new when the server suggests it, and only while the signal channel is empty so no queued request is dropped. A request landing after the check is handled by the server, which turns an unhandled signal at completion into a new workflow task.

MergeExportData stops persisting a marker — 049131a

exportDataToMergeInputs ran inside a workflow.SideEffect, which writes its return value into the history as a marker: every clip path, language and offset, recorded once as the marker and again in the activity inputs derived from it. The function reads no clock, file or global, so the SideEffect bought nothing.

It does range over the per-clip audio and subtitle maps, so those keys are now sorted — each language accumulates into its own MergeInput so the order was already immaterial, but running in workflow code it has to be visibly so, to workflowcheck and to the next reader.

No workflow.GetVersion guard: this changes what the workflow writes to its history, so an export started before the deploy fails to replay it. None has to survive the deploy.

CleanupTemp returns counts — 36d239c

It sweeps ~60 folders and returned every deleted path as its result, which goes into the completion event. DeletedFiles is replaced by DeletedCountPerRoot, which is what the result is actually read for — seeing a folder that is not being cleaned. Paths remain in the activity results and worker logs.

Also moved the per-folder log line below the error check, where it can report the folder it just finished: as written it logged the running total, so it printed 0 for the first folder however much it had deleted.

ImportSubtitles can take a path — ea0e06d

A word-level transcription of a long programme is megabytes, and a workflow argument lives in the WorkflowExecutionStarted event. A big enough one does not merely bloat the history, it exceeds Temporal's payload limit and the workflow cannot start.

SubtitlesFile is an alternative input read by an activity. Subtitles is kept, not replaced — nothing in this repository starts ImportSubtitles, so the field cannot go until whatever produces the transcription has moved over.

Dropped: VXExport sending children narrowed clips

The fifth sub-item, trimming the per-destination ExportData copies down to the clip fields the children read, is no longer in this PR. The parent history already carries the full ExportData twice — the GetExportDataActivity result and the MergeExportData child input, which has to be complete — so narrowing the destination copies saved a fraction of what was already there, on a payload never close to Temporal's limit. It bought that by making any field a child later reads silently zero. Not worth the trade.

🤖 Generated with Claude Code

[KillerX]

Trimmed in 1dd3280. You were right about the density — roughly a quarter of the lines this branch added were comment, and most of the excess was the commit message written into the source a second time.

What stays is the part that is not recoverable by reading the code: why the version gate exists, why the channel has to be empty before continuing as new, why the clip fields are narrowed and where to add one, and why the cleanup result carries counts instead of paths.

One went entirely rather than shrinking: the note explaining that the per-folder log line had moved below the error check described the change rather than the code, and the line reads fine on its own.

[KillerX]

Confirmed and fixed. e0f1a44 was a rebase error of mine, not a decision: when I rebased this branch onto the updated #448 I passed e6b5f21 as the upstream, and 8e90add sits inside that range — so git replayed the reverted commit on top of its own revert. It landed here rather than in #448, which is why it was missing from the description and why the stack ended up doing both things at once.

It is gone. This branch no longer touches workflows/ingest/incremental_ingest.go — the file list is the five payload changes and their tests, nothing else.

While in there I also removed the add-and-revert pair from #448 itself, so its history is now just the selector change and the copy/catch-up fix rather than three commits arguing with each other. The whole stack was rebased with the correct upstream this time and force-pushed; make test is green on the tip, and there are no revert or duplicate commits left anywhere in the 29.

[KillerX]

Related to the P1 on #448: the ContinueAsNew added here has the same problem, in a narrower form, and is now gated in 043709d.

GetContinueAsNewSuggested replays the value the server sent at the time, so an execution that had already crossed the suggest threshold before this deploys would emit CONTINUE_AS_NEW at a point where its history has a signal receive. It only bites a run that is both open at deploy time and already large — which is exactly the bulk move this change exists for. Behind versionContinueAsNew now, so those runs behave as they do today and the next one gets the new behaviour.

No test for it: the test environment cannot make GetContinueAsNewSuggested return true, so a test of the gated path would pass whether or not the gate were there. The commit says so rather than implying coverage.

To be clear about the other half of that review comment: this branch does not need a GetVersion gate for incremental_ingest.go. It no longer touches that file — the change that did was e0f1a44, the accidentally reintroduced transcode, removed before the review.