---
id: TST-PFM-DJE-137
title: Job list paging and filters
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-crm
files:
  - modules/data-jobs/tests/integration/services/persistence/data-jobs.queries.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-crm:modules/data-jobs/tests/integration/services/persistence/data-jobs.queries.integration.spec.js
assertion_inventory:
  - listing a tenant’s data jobs
  - the page a console reads
  - 'answers the tenant’s three jobs, newest first'
  - 'says nothing follows, because the three are the whole list'
  - >-
    answers every element of a job that has not started: its request, its state and the instants it
    has none of
  - leaves out the instants and the rollback link a waiting job has nothing for
  - 'answers the finished job with the counts, the batches and the instants its run left'
  - 'says the validated job has an impact digest to read, without putting the digest in the list'
  - 'answers the submitted instant as an ISO 8601 UTC timestamp, as every other read does'
  - the keyset page
  - answers the two newest jobs and a cursor to read on from
  - 'answers the job the first page stopped before, and nothing after it'
  - 'refuses a cursor it never answered, rather than paging from somewhere of the caller’s choosing'
  - the filters
  - narrows the list to one state
  - 'takes several states at once, which is how a console shows “still running”'
  - narrows the list to one mode
  - narrows the list to one submitter
  - answers every job for the one operation CRM performs (premise)
  - answers nothing for an operation no job of the tenant ran
  - >-
    narrows the list to one object type, which is what a collection’s own list is (premise: these
    are contact jobs)
  - >-
    answers nothing for an object type no job of the tenant is of, so the filter is not quietly
    ignored
  - leaves out the jobs submitted before the instant the range starts at
  - >-
    leaves out the jobs submitted after the instant the range ends at, and keeps the one submitted
    at it
  - 'intersects the filters it is given, so a state of another submitter’s job answers nothing'
  - the tenant the list is confined to
  - answers another tenant’s list with that tenant’s own job and nothing of this one
  - leaves the other tenant’s job out of this tenant’s list
  - 'listing and reading a tenant’s delivered data jobs: the conflict policy each runs under'
  - 'lists the delivery that named no policy under reject, the default, and the other under overwrite'
  - answers each delivery’s status with the policy it runs under
  - puts the policy on the status and the list rows the routes answer
  - listing a delivered data job
  - answers the delivered job alone (premise)
  - >-
    answers every element of its row, with the producer, the delivery, the file and the conflict
    policy it was submitted with
registration_note: Registration describes existing source; the suite is not executed by this documentation job.
---

# Job list paging and filters

## 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 job list paging and filters. 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

The owning service exercises production persistence and domain behavior against real Postgres. The fixture supplies caller contexts; queue delivery, storage and external calls are doubled where the file installs a test port.

## 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.