--- id: TST-PFM-DJE-122 title: 'Initial load, reset and reload' 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/jobs/initial-import-guarantees.integration.spec.js implements: - ATS-PFM-DJE-012-07 - ATS-PFM-DJE-012-09 - ATS-PFM-DJE-017-02 - ATS-PFM-DJE-017-04 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/jobs/initial-import-guarantees.integration.spec.js assertion_inventory: - 'an initial import of a whole tenant: re-run, resume, and reset and reload' - 'the package, loaded once' - applies every item of every file of an uninterrupted load - settles every job of an uninterrupted load as succeeded - 'writes the records the package holds, each with its crosswalk row' - 'keeps the archived option an initial import carries, as history' - writes the parent of every organization the parent pass names - writes the spouse of every contact the spouse pass names - 'resume: a load interrupted part way' - 'spans more than one batch of contacts, so stopping after one leaves work undone (premise)' - runs the first batch from its message before the client stops - acknowledges the committed batch delivered again without running it - applies nothing twice when the committed batch is delivered again - keeps what a worker committed before it died - >- applies nothing of the dead worker’s batch again when its message comes back, and finishes the batch - 'settles the resumed job as succeeded, every contact applied' - 'applies each item of the resumed job exactly once: one receipt per item, every one applied' - applies every item of every other file of the resumed load - 'leaves the tenant holding as many rows, table for table, as the uninterrupted load' - 'leaves the same records as the uninterrupted load, record for record' - 're-run: the same package loaded again' - skips every item of every file as a duplicate - 'settles every job of the re-run as succeeded, applying nothing' - 'changes no row of the tenant’s records, their collections, their history or the crosswalk' - leaves every contact’s and organization’s version as it was - 'reset and reload: the loading tenant reset, then loaded again' - answers done from every participant of the reset - held the package before the reset (premise) - >- removes everything the load wrote: no contact, organization, imported type or crosswalk row is left - 'leaves the other loading tenant’s row counts as they were, table for table' - 'leaves every row of the other loading tenant as it was, by a checksum of each table' - 'applies every item of every file of the reload, nothing being recognised from before the reset' - 'reloads as many rows, table for table, as the load before the reset' - 'reloads the same records as the load before the reset, numbers included' - an initial import of records with files - the organizations - >- applies every organization whose logo could be saved, and rejects the two that could not be written - 'settles the job as completed with rejections, not failed' - 'files the uploaded logo under its organization, through the asset pipeline' - keeps a Rhythm 1.0 permanent logo as the reference it is - reuses the Rhythm 1.0 permanent logo without copying it - >- rejects the organization whose logo was never uploaded as an invalid value of its logo, and only it - writes no crosswalk row for either rejected organization - 'the batch committed, its worker dead, and its message delivered again' - committed the organizations before the worker died (premise) - runs the batch again when its message comes back - 'copies the uploaded logo once, however often the batch is delivered' - files one attached logo for the organization - leaves the logo the organization was first given - a file prepared for a write that did not commit - >- is left ready, once per delivery that prepared it, naming a record that was never written (premise) - is claimed by the asset cleanup once its grace has passed - 'is discarded by the cleanup, nothing referencing it' - a contact - applies the contact - files the contact’s photo under the contact - files the contact’s image custom field under the contact - an initial import of an organization with a logo while the file storage is unavailable - 'fails the delivery that met the outage, for the queue to deliver it again' - leaves the job running and writes nothing while the storage is unavailable - applies the organization on the next delivery - files the logo under the organization registration_note: Registration describes existing source; the suite is not executed by this documentation job. --- # Initial load, reset and reload ## 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 initial load, reset and reload. 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.