---
id: TST-PFM-DJE-177
title: Run driver
kind: integration
product_area: platform
module: data-job-engine
revision: 1
status: draft
source_sha:
  services-platform: ad3f6a6582843008ed0f5a17b131878d15829af1
  macroservice-libraries: 54536a441935c6e09fdb7f96f0bec71c52ba4e03
  services-crm: a8d1364f1dd44b723bb5f9acba12f983e9ec8d69
  services-membership: 5994c270e8a37a30f848e99ba5b5ee6b87c08893
  react-console: baf6dae382d6f41dce976c7f848667ccc37e076f
repository: services-platform
files:
  - modules/data-jobs/tests/integration/services/runs/run-driver.integration.spec.js
implements:
  - ATS-PFM-DJE-016-06
  - ATS-PFM-DJE-016-07
  - ATS-PFM-DJE-016-08
  - ATS-PFM-DJE-016-09
  - ATS-PFM-DJE-016-11
environment: local
implementation_state: implemented
latest_result: not-run
latest_run_at: null
latest_run_ref: null
conformance: not-verified
estimated_minutes: 5
isolation: >-
  Suite-owned fixture records, job identifiers and workspace contexts; teardown removes the fixture
  data.
evidence:
  - >-
    services-platform:modules/data-jobs/tests/integration/services/runs/run-driver.integration.spec.js
assertion_inventory:
  - 'data runs: driving a run through its datasets'
  - starts the run and submits only the dataset that waits for nothing
  - 'asks the macroservice that owns the object type, over its own route for that object'
  - 'forwards the staff caller’s own token with every call, and invents no identity of its own'
  - records the job the owning service created against the step that was submitted
  - leaves a running step where it is while its job is still running
  - moves on to the next dataset once the one it depends on has finished
  - records what the owning service counted against the step that finished
  - 'finishes the run succeeded once every dataset has, and stops asking anybody anything'
  - 'never submits a dataset before the one it depends on, however many passes are made'
  - 'data runs: a run that stops'
  - 'fails the run at the first dataset that failed, in the owning service’s own words'
  - 'skips the datasets a failed run never attempted, so a reader sees what was not loaded'
  - submits nothing more once the run has failed
  - 'fails the step when its owning service cannot be read at all, rather than running for ever'
  - 'refuses to start a run that has already failed: a corrected package is a new run'
  - 'pauses a running run where it stands, and submits nothing while it is paused'
  - 'continues a paused run from where it stood, keeping what had already finished'
  - refuses to resume a run that is not paused
  - 'cancels the jobs a cancelled run had already submitted, in their own services'
  - skips the datasets a cancelled run never submitted
  - 'data runs: a dataset that could not attempt every record'
  - >-
    keeps the run going when a dataset finished with records it could not attempt, and records how
    many
  - 'does not hold the rest of the run up for a blocked dataset: what depends on it goes on'
  - 'tries a blocked dataset a second time, and only a second time'
  - 'finishes a run whose last dataset settled blocked, and says so in the readiness of its summary'
registration_note: Registration describes existing source; the suite is not executed by this documentation job.
---

# Run driver

## Verification Boundary

The suite checks the production service or shared engine against its database fixture. The structured assertion inventory records the checks present at the pinned revision.

## What This Suite Proves

The existing checks exercise run driver. The specification bindings identify the narrower outcomes supported by those assertions.

## What It Does Not Prove

Local execution does not establish deployed queue, storage or service behavior. Independent test cases do not establish a complete cross-feature process.

## Real Dependencies and Test Doubles

Run registration and progression use real Postgres. Child-job calls and uploaded input are supplied through test ports, so remote service deployment is outside this boundary.

## Must Not Be Doubled

The database effects, security context and production operation under examination remain real. Their outcomes cannot be replaced with canned success responses.