Feature Proposal: Task Lifecycle Tracking Extensions

[gdeyoung]

Summary

I've built a superset of this plugin that adds task lifecycle tracking for scheduled/recurring tasks. I'd like to propose contributing these additions back to the community plugin.

What We Added

On top of the excellent workspace heartbeat features (which we kept unchanged), we added:

Task Lifecycle API

• task_register - Register a new task with PID, timeout, and optional chat association
• task_ping - Update task progress (heartbeat for long-running tasks)
• task_complete - Mark task done with result
• task_fail - Mark task failed with error
• task_check - PID-aware health check of all tracked tasks
• task_list / task_status - Query task states
• task_cleanup - Remove old completed/failed tasks

Reliability Features

• PID tracking with zombie detection (/proc filesystem + os.kill)
• Circuit breaker - After 3 API failures, falls back to local JSON files
• File-based fallback - Tasks can register/complete even when A0 API is down
• Auto-retry - Stale tasks (no ping for 2h) auto-reset to idle
• Dead process detection - Watchdog can find and report silently crashed tasks

Observability

• Central Node Registry (registry.json) - All task states in one read
• Correlation IDs - X-Correlation-ID header on every API call for tracing
• WebUI Dashboard - Task health, history, progress tracking

Why This Matters

The workspace heartbeat answers: "Does anything need attention?"

Task lifecycle answers: "Is scheduled task X still running? Did it crash silently?"

For anyone running 10+ scheduled tasks (backups, reports, health monitors, data pipelines), this is critical infrastructure.

Files Changed

All additions are in separate files - the existing workspace heartbeat code is untouched:

• helpers/task_lifecycle.py - Core lifecycle logic
• api/task_register.py through api/task_registry.py (8 new API handlers)
• scripts/heartbeat_api.py - REST client for subprocess tasks
• WebUI dashboard extensions

Compatibility Notes

Current implementation:

• Linux-only PID detection (uses /proc filesystem)
• Requires CSRF auth for API client
• File-based locking with fcntl.flock

Before contributing, we would:

• Add Windows-compatible PID detection fallback
• Make API base URL configurable (not hardcoded localhost)
• Document auth requirements clearly

Questions

1. Would you be open to a PR adding these features?
2. Should we keep everything in one plugin, or split into two (workspace heartbeat + task lifecycle)?
3. Any concerns about the file-based approach vs a database?

Happy to submit a clean PR if this aligns with the project's direction.