 |
VOOZH | about |
|
VOOZH | about |
The Schedule Watcher monitors scheduled tasks (cron jobs) executed by the Hypervel framework's task scheduler. It captures information about each scheduled task execution, including the command, cron expression, output, and execution status. This watcher provides visibility into automated background tasks that run on a schedule.
For information about monitoring console commands triggered manually, see Command Watcher. For information about monitoring queued jobs, see Additional Watchers.
The Schedule Watcher differs from most other watchers in that it only activates when the application is running in scheduler context. It performs an explicit check for the scheduler commands crontab:run or schedule:run in the $_SERVER['argv'] array before registering its event listeners.
Activation Check: $_SERVER['argv'][1] in ['crontab:run', 'schedule:run']
This conditional registration ensures that the watcher only imposes overhead during scheduled task execution, not during normal HTTP requests or other command executions.
Sources:
The Schedule Watcher monitors three lifecycle events dispatched by the Hypervel console scheduler:
| Event Class | Trigger Point | Purpose |
|---|---|---|
Events\ScheduledTaskStarting | Before task execution begins | Enables recording for the task |
Events\ScheduledTaskFinished | After task completes successfully | Records task details and output |
Events\ScheduledTaskFailed | After task fails with exception | Records task details and failure information |
Sources:
The Schedule Watcher's registration process is unique among watchers:
The watcher stores both the container instance and the EntriesRepository as instance properties because it needs them later for immediate storage operations, which differs from the deferred storage pattern used by most other watchers.
Sources:
When a scheduled task completes or fails, the watcher creates an entry with comprehensive task metadata:
| Field | Source | Description |
|---|---|---|
command | $task->command | The console command string (or 'Closure' for callbacks) |
description | $task->description | Human-readable task description |
expression | $task->expression | Cron expression defining the schedule |
timezone | $task->timezone | Timezone for schedule evaluation |
user | $task->user | User context for task execution |
output | $task->getOutput($app) | Captured console output from the task |
The watcher distinguishes between two types of scheduled tasks:
When the scheduled task is a CallbackEvent (a closure-based task), the command field is set to the string 'Closure' rather than attempting to serialize the callback. For command-based tasks, the actual command string is captured.
Sources:
Unlike most watchers that defer storage to request completion, the Schedule Watcher uses an immediate storage pattern:
This immediate storage is necessary because:
The watcher explicitly calls Telescope::store($this->entriesRepository) after recording each entry, bypassing the normal deferred storage mechanism.
Sources:
The Schedule Watcher manages recording state across task executions:
During registration, the watcher calls Telescope::startRecording() to enable monitoring for the entire scheduler run. This ensures that any nested operations (database queries, cache operations, etc.) performed by scheduled tasks are also captured by their respective watchers.
When a ScheduledTaskStarting event fires, the watcher calls Telescope::startRecording() again. This resets the recording context for the new task, ensuring each task's operations are properly tracked.
Before recording task completion, the watcher verifies that recording is active:
if (! Telescope::isRecording()) {
return;
}
This check prevents recording entries when Telescope is paused or disabled.
Sources:
The Schedule Watcher is configured in the telescope.php configuration file under the watchers array:
| Option | Type | Default | Description |
|---|---|---|---|
enabled | bool | true | Enable or disable scheduled task monitoring |
The Schedule Watcher does not support additional configuration options such as ignore lists or size limits because scheduled tasks are typically administrative operations that should always be monitored when the watcher is enabled.
Sources:
The Schedule Watcher interacts with several framework components:
The watcher depends on:
Sources:
The Schedule Watcher captures console output from scheduled tasks by calling $task->getOutput($this->app). This method retrieves the buffered console output produced during task execution, providing visibility into what the task printed, logged, or displayed.
The container instance ($this->app) is passed to the output retrieval method, allowing the task to access application services if needed during output generation.
Sources:
Entries created by the Schedule Watcher are classified with the type 'schedule', which allows them to be filtered and queried in the Telescope UI. The Telescope::recordScheduledCommand() method internally creates an IncomingEntry with this type designation.
This classification enables developers to:
Sources:
Refresh this wiki