Skip to content

Observation tasks

A task is the atomic unit of execution on a telescope. When the scheduler decides to run part of your observation, it creates one or more ObservationTask records — each task is "this specific request, on this specific telescope, with this specific instrument, at this specific start time."

The tasks panel on the observation detail page is the per-task view: one row per task with progress, telescope assignment, and timing.

Per-task columns

The panel shows:

Column What it means
ID Stable task identifier — useful when correlating with telescope logs
Type The kind of task (optical imaging / radio tracking / radio mapping / calibration). Polymorphic, mirroring the request types in the editor
Telescope Which telescope the scheduler assigned the task to
Status Pending / scheduled / running / completed / failed / canceled
Progress % For active tasks, the executor's reported progress (0 → 1)
Planned start When the scheduler intends the task to begin
Observing window The time range when the task is eligible to run
Completed at Timestamp on completion

The table auto-refreshes on a ~20-second cadence while the observation is active.

How tasks relate to requests

The relationship is one-to-many: each ObservationRequest in your observation can produce multiple tasks depending on:

  • Iterations — every iteration of the observation produces another set of tasks.
  • Per-request iterations — likewise inside a request that loops.
  • Tiling — large optical imaging targets that exceed a single field of view spawn one task per tile.
  • Sweep elements — radio mapping requests with daisy or raster patterns can spawn multiple tasks for distinct sweep elements.
  • Assignment modes — parallel and parallel_synchronized modes spawn tasks on multiple instruments simultaneously.

Tasks are reassigned through ObservationTaskAssignmentHistory records if the scheduler moves a task between instruments mid-flight (rare, but it happens — instrument lock timeout, hardware fault).

When a task fails

A failed task carries an error and a reason. Common cases:

  • Weather / constraint failure — the telescope was eligible at scheduling time but a constraint tripped before the task started. The scheduler will typically re-queue the task on the next cycle unless the observation's cancel_on window has passed.
  • Instrument failure — a device went offline mid-task. The task is marked failed; if the observation allows reassignment, the scheduler retries.
  • Constraint violation during task — a constraint that was OK at start fell over (cloud rolled in). The task is interrupted; what the executor produced is uploaded as a partial result and the scheduler re-queues.

Most transient failures self-heal on the next scheduler cycle. If a task keeps failing in the same way, that's a telescope-side problem worth flagging to the owner; the tasks panel is where you'd notice the pattern.

What to do with task IDs

Task IDs are useful when:

  • Correlating with telescope logs — the telescope owner can use the task ID to find the exact log lines for that task.
  • Filing a problem report — quoting the task ID gives operators the exact context to investigate.
  • Pulling data through the API — task IDs key into ObservationAsset.task_info, which is how files trace back to the task that produced them.

Component reference