Skip to main content
HookEvent.JOB_COMPLETED fires from BackgroundJobManager.start_job whenever any managed background job reaches a terminal state — completed or failed. Register a hook to log completions, send alerts, or trigger follow-up work.
The user starts background work; your JOB_COMPLETED hook runs when the subagent finishes or fails.

How It Works

Quick Start

1

Create a hook registry

2

Register a JOB_COMPLETED handler

3

Attach to your agent


How It Works

The user delegates work to a background job; when the job ends, the hook fires with the outcome.

JobCompletedInput Fields

JobCompletedInput carries everything about the finished job, including the delivery context if one was set. All origin fields are strings — empty ("") when not set. Origin fields (session_id, deliver, platform, chat_id, thread_id) are always strings — an empty string when not set.

Behaviour Notes

  • Fires for every managed background job, not only those launched via spawn_subagent(background=True)BackgroundJobManager.start_job emits it directly at the terminal path.
  • Fires on both success and failure. Check data.status ("completed" or "failed") to distinguish.
  • Does not fire for CANCELLED or LOST. The enum documents “finished ok or error”; that contract was deliberately not widened.
  • Best-effort. A raising hook never crashes the background worker — exceptions are caught and logged.
  • Sits alongside SCHEDULE_TRIGGER. Both fire in the background-job lifecycle and follow the same hook shape.

Logging Example

The shortest copy-paste hook that logs every completion to a file:

Best Practices

Background jobs may be retried or replayed. Design your JOB_COMPLETED hook so running it twice for the same job_id produces no unintended side effects — for example, check if a log entry already exists before appending, or use an upsert rather than an insert.
The hook dispatcher is synchronous by default. Avoid slow I/O (database writes, HTTP calls) inside the hook body — offload to a thread pool or enqueue to a background queue instead:
Per the hook dispatcher in praisonaiagents/hooks/runner.py, exceptions raised inside a hook are caught and logged — they never crash the background worker. Use this as a safety net, but do not rely on it: log errors explicitly so failures are visible.
If a completed job should trigger another agent, use the deliver field to route the result back through the gateway — do not call a second agent inline from the hook. Inline calls block the dispatcher and can create nested background jobs that are harder to trace.
Use data.status to distinguish success from failure. Only trigger alerts or follow-up workflows when status == "failed" to avoid noise from normal completions.
No. deliver is empty for background jobs the caller did not route anywhere. The event still fires for every managed job; an empty deliver just means there is no delivery target attached.

Subagent Tool

Spawn background subagents with deliver= routing

Hook Events

Full hook system reference — all events and patterns

fire_hook

How lifecycle events are emitted to subscribers