OTel

Ask an activation to stop at the next chunk boundary.

Changed on
post/otel/cloud-telemetry/bulk-jobs/{batch_id}/cancel

Request

  • Base URL: /api (relative, and the document was published on a file host, not at the API’s origin)
  • URL: /api/otel/cloud-telemetry/bulk-jobs/{batch_id}/cancel
  • Auth: HTTP bearer

Path parameters

batch_idstring required

Activation job id (UUID)

Response

The cancellation was recorded, or the job had already stopped

abort_detailstring nullable

The same reason as a sentence naming the fix and the page that applies it.

abort_reasonstring nullable

Machine-readable instance-wide abort reason, e.g. not_linked.

batch_idstring required
bytes_shippedinteger required
cancel_requestedboolean required

Set as soon as a cancel is requested, before the worker honours it at the next chunk boundary — so the UI can stop offering Cancel twice.

cancel_requested_atstring date-time nullable
completed_atstring date-time nullable
created_atstring date-time required
current_project_idinteger nullable

The project being switched or backfilled right now.

estimated_bytesinteger required
estimated_spansinteger required
eta_secondsinteger nullable

Seconds remaining, or null when eta_state is not known.

eta_state'estimating' | 'known' | 'finished' required

How much of the ETA this instance can honestly claim to know.

observed_spans_per_secnumber double nullable

The average this job has actually achieved since it started. Sent so the client can render a coarse rate instead of implying a precision the average does not have.

percent_completenumber double nullable
plan_hashstring nullable
projects_doneinteger required
projects_failedinteger required
projects_pendinginteger required
projects_skippedinteger required
projects_totalinteger required
requested_by_user_idinteger nullable
spans_shippedinteger required
started_atstring date-time nullable
status'pending' | 'running' | 'completed' | 'completed_with_failures' | 'aborted' | 'cancelled' required

Lifecycle of a bulk job.

The three terminal-with-a-problem states are deliberately distinct. completed_with_failures means the job ran to the end and some projects did not; aborted means an instance-wide condition stopped it and the untouched projects are still pending, ready to resume; cancelled means an operator asked it to stop. Collapsing any two of those would leave the Console unable to say what to do next.

trigger'purchase' | 'operator' required

Which entry point created the job (ADR-042 §1).

The engine does not branch on this. It exists so an operator disputing an invoice, or reading an audit trail, can tell "this instance spent money because someone clicked a button" apart from "…because a purchase completed and the payment was the authorization".

Changes

    • info

      added the optional property to the response with the status

    • info

      added the optional property to the response with the status

    • info

      added the optional property to the response with the status

    • info

      added the optional property to the response with the status

    • warning

      removed the optional property from the response with the status

    • warning

      removed the optional property from the response with the status

    • warning

      removed the optional property from the response with the status

    • warning

      removed the optional property from the response with the status