hermes - 💡(How to fix) Fix Feature: Job chaining — trigger one cron job from another's completion [1 participants]

Feature Description

Allow cron jobs to be triggered (or chained) based on the completion of another cron job. Currently, jobs run on independent schedules and there is no native mechanism to say "run Job B immediately after Job A finishes successfully."

Motivation

This would enable powerful automation pipelines:

1. Data pipeline: Job A collects raw data → Job B transforms it → Job C generates a report — each triggering the next automatically
2. Conditional execution: "Only run the email digest if the health check passed"
3. Fan-out patterns: One source job triggers multiple consumer jobs in parallel
4. Dependency management: Ensure tasks execute in the correct order without manual schedule coordination

This is a common pattern in workflow orchestrators (Airflow DAGs, Prefect flows, GitHub Actions workflow_run) and would significantly reduce the complexity of chained automations in Hermes.

Proposed Solution

The most natural approach would be extending the existing cronjob tool with one or more of these mechanisms:

Option A — depends_on (recommended as primary)

Add a depends_on field when creating/updating a job:

depends_on:
  - job_id: "abc123"
    status: "ok"           # only trigger if parent finished with this status

When the parent job completes with matching status, the child job enqueues immediately.

Option B — triggers (for fan-out)

A parent job can declare which child jobs to trigger on completion:

triggers:
  - job_id: "xyz789"
    data_passthrough: true  # inject parent output as child context

Option C — Event hook in context_from

Extend the existing context_from parameter to optionally become a reactive trigger by adding a trigger_on_complete: true flag:

context_from: "abc123"
trigger_on_complete: true   # instead of waiting for next schedule, run immediately

Implementation Considerations

• Circular dependency detection: Prevent A→B→A loops
• Concurrency limits: Prevent resource exhaustion from cascading triggers
• Timeout/backpressure: What happens if child jobs queue up faster than they can execute?
• Status propagation: A child job should know the exit status and output of the parent
• Delivery: How should chained job results be delivered? Inherit from parent? Configurable?

Alternatives Considered

1. Manual schedule coordination — what currently exists; fragile and imprecise (works only with large time buffers)
2. Single monolithic job — works for simple chains but couples concerns and makes debugging harder
3. External orchestrator — adds unnecessary infrastructure complexity for what should be a core feature

Priority

P3 — Low (nice to have). The current context_from + offset schedules work as a passable workaround, but native chaining would be a significant UX improvement for multi-step automation workflows.