fix(vizualizer): heartbeat while waiting for a visualization job - #445
Open
KillerX wants to merge 1 commit into
Open
fix(vizualizer): heartbeat while waiting for a visualization job#445KillerX wants to merge 1 commit into
KillerX wants to merge 1 commit into
Conversation
WaitForVisualization is a poll loop with no heartbeat, scheduled from VXExportToVOD under GetDefaultActivityOptions, which sets a ten minute HeartbeatTimeout. Its own poll Timeout is two hours. Those two numbers contradict each other: a visualization takes about as long as the audio it renders, so anything past ten minutes is killed mid-render, retried, and killed again at the same point. Ten identical failures, then the export gives up — and the render itself was fine. Each poll now records a heartbeat, with the job status as the detail so a slow but progressing job is visible rather than merely silent. This is the pattern WaitForFileVisibleInStorageActivity already uses; the rest of the long-running activities go through newHeartBeater or simpleHeartBeater in common.go. Fixed here rather than by leaving HeartbeatTimeout out of the defaults: the timeout is right, the activity was the thing not holding up its end. Checked the other activities that heartbeat nowhere — they are single API calls or, in CropShortActivity's case, pure argument building. The one worth a second look is GetAudioDiff, which makes an unbounded HTTP request to the sync service and drops its context entirely, so it can neither heartbeat nor be cancelled; logged rather than reworked here. Verified: the test records zero heartbeats without the fix. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
6/n of a stack. Base:
fix/generate-short-options-before-first-activity(#444).This is the finding I pointed at from #443: the heartbeat trap, fixed at the activity rather than by weakening the defaults.
WaitForVisualizationis a poll loop with no heartbeat, scheduled fromVXExportToVODunderGetDefaultActivityOptions, which sets a ten minuteHeartbeatTimeout. Its own pollTimeoutis two hours. Those two numbers contradict each other: a visualization takes about as long as the audio it renders, so anything past ten minutes is killed mid-render, retried, and killed again at the same point. Ten identical failures, then the export gives up — and the render itself was fine.Each poll now records a heartbeat, with the job status as the detail so a slow but progressing job is visible in Temporal rather than merely silent. This is the pattern
WaitForFileVisibleInStorageActivityalready uses; the other long-running activities go throughnewHeartBeater/simpleHeartBeaterincommon.go.The timeout was right — the activity was the thing not holding up its end, which is why this is fixed here and not by dropping
HeartbeatTimeoutfrom the defaults.I checked the other activities that heartbeat nowhere. All single API calls, or pure argument-building in
CropShortActivity's case. One is worth a second look and is not fixed here:GetAudioDiffmakes an unbounded HTTP request to the sync service and takes_ context.Context, so it can neither heartbeat nor be cancelled.Verified: the test records zero heartbeats without the fix.
🤖 Generated with Claude Code