---
id: TST-PFM-DJE-175
title: Data run ports
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/data-run-ports.integration.spec.js
implements: []
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/data-run-ports.integration.spec.js
assertion_inventory:
  - >-
    data runs: a staff member with a standing grant on the tenant’s customer drives a Platform step
    in process
  - >-
    is driven from a route context that does not itself allow the custom-field keys, as the HQ
    route’s does not (premise)
  - submits the definitions first and holds the dataset that waits for them
  - 'asks no other macroservice anything to do it: the step never leaves this process'
  - 'records a data job of Platform’s own against the step, submitted by the staff member themselves'
  - 'names the producer the run’s own row names, so the crosswalk is keyed by the producer’s ids'
  - >-
    writes the definitions the dataset carried into the tenant, through the metadata module’s own
    create
  - stamps the definitions with the staff member who drove the run
  - 'loads them into the tenant the run is of and into no other, the tenant coming from the run’s row'
  - copies what the job counted onto the step when a later read polls it in process
  - >-
    goes on to the dataset another macroservice owns once the definitions have finished, over the
    remote port
  - still carries the staff caller’s own token to the macroservice that is somewhere else
  - 'finishes the run succeeded, each dataset having been loaded by whoever owns it'
  - >-
    data runs: a staff member who may drive a run but holds no right to change the tenant’s
    definitions
  - >-
    loads the definitions for a staff member whose standing Administrator grant reaches the tenant
    (the positive control)
  - >-
    refuses a staff member with no grant in the tenant, whose platform-scope authority counts on the
    HQ route alone
  - refuses a staff member whose standing grant is on another customer
  - refuses a staff member whose grant on the tenant’s customer is of a role without the bulk key
  - >-
    writes nothing when the start was refused: no definition, no data job, and the run still
    registered
  - 'leaves the run where it stood when it was refused, so a staff member who may load it still can'
  - >-
    refuses a later read of a running run to a staff member with no grant, and leaves its steps as
    they stood
  - >-
    refuses the cancellation of a running Platform step to a staff member with no grant, leaving the
    run running
  - 'data runs: cancelling a run whose Platform step has a job of Platform’s own'
  - cancels the run and skips the dataset it never submitted
  - >-
    takes the cancellation of a Platform step to the engine in process, and asks no macroservice to
    do it
  - 'leaves the records the step had already committed, because a cancellation undoes nothing'
registration_note: Registration describes existing source; the suite is not executed by this documentation job.
---

# Data run ports

## 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 data run ports. 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.