BUG: Stage errors after BeginStage leave tasks stuck

[STRRL]

Summary

When a task stage (download/transcribe/summarize) calls BeginStage successfully but later hits an error path that returns without going through recordTaskError, the task status stays in the in-progress state (e.g. downloading). The Error field remains empty, so the UI believes the stage is still running and blocks manual retries. This effectively deadlocks the task until the backend restarts.

Impact

• Users cannot recover a task after certain transient failures (for example, an UpdateTaskStatus persistence error).
• Buttons remain disabled on the Task page because the stage appears busy.

Proposal

Introduce a helper (e.g. withStage(...)) or a defer wrapper that guarantees we persist a failure state whenever a stage function exits with an error after BeginStage has succeeded. This likely requires a broader rethink of stage orchestration, so we should track it separately to unblock the current PR.

References

• app.go:308-396, app.go:357-411, app.go:417-505
• internal/services/taskmanager.go:123-157

[STRRL]

Adding another observation about the stage orchestration: each stage function currently performs manual status validation ( blocks in ) before calling , but itself repeats similar guard checks. The duplication increases the risk of divergence and confusing error messaging. Once we redesign the stage helper, we should consolidate these validations into a single source of truth.

[STRRL]

Adding another observation about the stage orchestration: each stage function currently performs manual status validation (switch blocks in app.go) before calling BeginStage, but BeginStage itself repeats similar guard checks. The duplication increases the risk of divergence and confusing error messaging. Once we redesign the stage helper, we should consolidate these validations into a single source of truth.

[STRRL]

Another follow-up for the stage refactor: the current mixture of immediate ClearTask and deferred scheduleCleanup makes it hard to reason about task lifetime. We decided to tackle this with a centralized background cleanup loop that owns task eviction; this should fold nicely into the broader stage orchestration redesign tracked here.