Audit of PR #294

The approach is sound — comparing error vs running timestamps per slot is the right way to detect failed rolling updates where old replicas mask the failure. A few findings:

1. Duplicated function

activeDeploymentErrorsByService() is copy-pasted identically across views/services/update.go and views/stacks/update.go. Same issue already exists with latestTasksByServiceKey(). Any future bug fix needs to be applied in two places.

2. No time cutoff

The existing error-detection code uses a 5-minute cutoff (newestTaskTime.Add(-5 * time.Minute)) to avoid surfacing stale historical errors. The new function has no cutoff — if a slot has an old failed task from hours/days ago and no running task for that slot, it will be flagged indefinitely.

3. Empty errMsg edge case

A task with State == TaskStateFailed but Status.Err == "" will set serviceHasError = true while leaving serviceErrorText as an empty string. The services view guards against this at line 684, but the stacks view path may not.

4. Non-deterministic error selection

if _, seen := result[s.serviceID]; !seen means which slot's error surfaces for a multi-slot service depends on Go map iteration order.

5. No tests

Both latestTasksByServiceKey and activeDeploymentErrorsByService are pure functions — highly testable. Given this is the second fix attempt for the same bug, tests would prevent regression.

I'll open a PR into this branch addressing these points.