openclaw - 💡(How to fix) Fix Task status should separate current failures from retained historical task records

Hi,

I ran into a case where openclaw status made the system look much worse than it actually was.

The Tasks section showed a large number of issues and warnings, but after looking into it more closely most of them were retained historical task records, not current operational failures.

In my setup this resulted in something like:

• 46 task issues
• 6 task audit warnings

At first glance this looks like a live problem. In reality the majority of those rows were old terminal task records such as:

• failed
• timed_out
• lost
• delivery_failed
• backing session missing

Some were caused by old cron-wrapper problems that had already been fixed, some by gateway restart/draining situations, and some by old subagent/control-task rows. They were still useful as history, but they should not keep the normal status view red forever.

What I observed:

• openclaw tasks list --json still contained retained terminal task rows.
• openclaw tasks audit --json reported warnings for retained/lost rows.
• openclaw tasks maintenance --json previewed TaskFlow pruning, but did not prune the task rows that were responsible for the visible task status noise.
• After manually archiving and cleaning reviewed stale terminal rows, task status returned to 0 issues / 0 warnings.

Locally I worked around this by separating the task summary into current, retained and soft-retained issue counts. That made the operational status meaningful again, but this is only a local workaround on my side and not a proper upstream solution.

I think the status model should distinguish these cases natively.

Expected behaviour:

• Current/live task failures should be counted as current issues.
• Retained historical failures should remain inspectable, but should not make the main status look unhealthy forever.
• Soft retained cases, for example known gateway restart/draining delivery failures or missing backing sessions after review, should be classified separately.
• There should be a supported cleanup/ack/prune path for reviewed stale terminal task rows.

A possible model could expose something like:

• currentIssues
• retainedIssues
• softRetainedIssues

And the normal status output should primarily alert on currentIssues.

This would make the Tasks status much more useful operationally. Historical task failures are important, but once reviewed and no longer live they should not permanently pollute the normal health view.

Thanks!