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 five of the Unbounded workflow histories finding, after the two loops in #447 and #448.

MoveFilesWorkerFlow continues as new — 0498ba9

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 — 4ca34f9

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.

Guarded with workflow.GetVersion, same reasoning as #448: an export started before this recorded a marker, and replaying it without one fails the workflow task, which Temporal retries forever.

CleanupTemp returns counts — fdfd164

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 — d04b386

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.

VXExport sends children only what they read — 3aa26bc

Each destination child gets the whole ExportData, written into the parent's history once per destination and into each child's again. Most of it is per-language material no child reads: the only thing a child does with a clip is hand it to GetTimedMetadataChaptersActivity, which needs the VXID and the in/out points.

clipsForChapterLookup narrows the copy to five fields. The hazard is a child later reading a field that is now silently zero, so TestClipsForChapterLookup pins the surviving set as a contract.

🤖 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.