Canceling a parent pipeline: are downstream pipelines left running?

GitLab documents a REST endpoint, POST /projects/:id/pipelines/:pipeline_id/cancel, that marks a pipeline as canceled and asks the runner to terminate its active jobs. Job-level timeouts and runner-side SIGTERM handling are separate documented mechanisms that interact with cancellation. Assume a current release line (GitLab 17.x) on SaaS or self-managed instances.

The unresolved part is scope. Downstream pipelines started through trigger (bridge) jobs appear as separate pipelines, and the documented cancel endpoint takes a single pipeline ID with no cascade option called out. Whether canceling the parent should stop same-project child pipelines, multi-project downstream pipelines, or neither is not clearly defined, so teams automating cancellation cannot tell which pipelines they remain responsible for. A related ambiguity is the final status reported when a job's timeout expires while cancellation is already in flight.

Behavior may also differ between Community and Enterprise editions and across runner versions, so this needs confirmation against current documentation before automation is built on it.

• Does canceling a parent pipeline cascade to same-project child pipelines, and to multi-project downstream pipelines?
• If not, is canceling each downstream pipeline individually the intended contract for API consumers?
• When timeout and cancellation race, which final job status is authoritative?