--- id: TST-PFM-NOT-077 title: cancel and supersede kind: integration product_area: platform module: notifications revision: 1 status: draft source_sha: services-platform: ad3f6a6582843008ed0f5a17b131878d15829af1 repository: services-platform files: - >- modules/notifications/tests/integration/services/orchestration/cancel-and-supersede.integration.spec.js implements: - ATS-PFM-NOT-005-01 - ATS-PFM-NOT-005-02 - ATS-PFM-NOT-005-03 - ATS-PFM-NOT-005-04 - ATS-PFM-NOT-005-05 - ATS-PFM-NOT-005-06 - ATS-PFM-NOT-006-01 - ATS-PFM-NOT-006-02 - ATS-PFM-NOT-006-03 - ATS-PFM-NOT-006-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 records in the prepared integration workspaces; seeded workspace identities remain shared fixtures. assertion_bindings: - scenario: ATS-PFM-NOT-005-01 suite: TST-PFM-NOT-077 assertions: - >- services-platform:modules/notifications/tests/integration/services/orchestration/cancel-and-supersede.integration.spec.js#folds five requests into one notification carrying the latest data and the count - >- services-platform:modules/notifications/tests/integration/services/orchestration/cancel-and-supersede.integration.spec.js#does not fold a request about another record - >- services-platform:modules/notifications/tests/integration/services/orchestration/cancel-and-supersede.integration.spec.js#does not fold a request for another person - >- services-platform:modules/notifications/tests/integration/services/orchestration/cancel-and-supersede.integration.spec.js#does not fold when the definition switches collapsing off - scenario: ATS-PFM-NOT-005-02 suite: TST-PFM-NOT-077 assertions: - >- services-platform:modules/notifications/tests/integration/services/orchestration/cancel-and-supersede.integration.spec.js#makes a new, unread notification when the one it would fold into was read - >- services-platform:modules/notifications/tests/integration/services/orchestration/cancel-and-supersede.integration.spec.js#makes a new notification when the one it would fold into was archived - >- services-platform:modules/notifications/tests/integration/services/orchestration/cancel-and-supersede.integration.spec.js#does not fold a request into an instance that was superseded - >- services-platform:modules/notifications/tests/integration/services/orchestration/cancel-and-supersede.integration.spec.js#still folds into a notification that is unread and unarchived - scenario: ATS-PFM-NOT-005-03 suite: TST-PFM-NOT-077 assertions: - >- services-platform:modules/notifications/tests/integration/services/orchestration/cancel-and-supersede.integration.spec.js#folds requests of the same scope and keeps requests of another scope apart - >- services-platform:modules/notifications/tests/integration/services/orchestration/cancel-and-supersede.integration.spec.js#folds a request that names no scope into one that does, and the other way - scenario: ATS-PFM-NOT-005-04 suite: TST-PFM-NOT-077 assertions: - >- services-platform:modules/notifications/tests/integration/services/orchestration/cancel-and-supersede.integration.spec.js#folds five requests into one notification carrying the latest data and the count - scenario: ATS-PFM-NOT-005-05 suite: TST-PFM-NOT-077 assertions: - >- services-platform:modules/notifications/tests/integration/services/orchestration/cancel-and-supersede.integration.spec.js#folds ten requests dispatched at the same moment into one notification of collapsed count nine - >- services-platform:modules/notifications/tests/integration/services/orchestration/cancel-and-supersede.integration.spec.js#does not make one identity wait for the lock another holds - >- services-platform:modules/notifications/tests/integration/services/orchestration/cancel-and-supersede.integration.spec.js#makes a request for the identity another transaction holds wait until it commits - scenario: ATS-PFM-NOT-005-06 suite: TST-PFM-NOT-077 assertions: - >- services-platform:modules/notifications/tests/integration/services/orchestration/cancel-and-supersede.integration.spec.js#keeps the notification when the first of its requests ends, handing it to the next and dropping the count - >- services-platform:modules/notifications/tests/integration/services/orchestration/cancel-and-supersede.integration.spec.js#renders the message again from the newest request left when the newest ends - >- services-platform:modules/notifications/tests/integration/services/orchestration/cancel-and-supersede.integration.spec.js#keeps the notification when a request it only folded ends, and supersedes it when the last one ends - >- services-platform:modules/notifications/tests/integration/services/orchestration/cancel-and-supersede.integration.spec.js#withdraws only the notice of the assignment that ended when two units were told apart - scenario: ATS-PFM-NOT-006-01 suite: TST-PFM-NOT-077 assertions: - >- services-platform:modules/notifications/tests/integration/services/orchestration/cancel-and-supersede.integration.spec.js#leaves nobody told and records the request cancelled when the cancel names the publish’s key - >- services-platform:modules/notifications/tests/integration/services/orchestration/cancel-and-supersede.integration.spec.js#leaves nobody told when the cancel names only the supersede key, even when the publish arrives after it - >- services-platform:modules/notifications/tests/integration/services/orchestration/cancel-and-supersede.integration.spec.js#does not cancel a publish submitted after the cancel - >- services-platform:modules/notifications/tests/integration/services/orchestration/cancel-and-supersede.integration.spec.js#records the cancel of a request that has no record as a cancelled request under the publish’s id - scenario: ATS-PFM-NOT-006-02 suite: TST-PFM-NOT-077 assertions: - >- services-platform:modules/notifications/tests/integration/services/orchestration/cancel-and-supersede.integration.spec.js#marks the instance superseded, leaves it readable and takes it out of the unread count - >- services-platform:modules/notifications/tests/integration/services/orchestration/cancel-and-supersede.integration.spec.js#finds the request by the supersede key alone - >- services-platform:modules/notifications/tests/integration/services/orchestration/cancel-and-supersede.integration.spec.js#does nothing the second time the cancel is processed - >- services-platform:modules/notifications/tests/integration/services/orchestration/cancel-and-supersede.integration.spec.js#leaves a request that had settled as it was - scenario: ATS-PFM-NOT-006-03 suite: TST-PFM-NOT-077 assertions: - >- services-platform:modules/notifications/tests/integration/services/orchestration/cancel-and-supersede.integration.spec.js#cancels the queued delivery and its work row, and does not recall one that already left - >- services-platform:modules/notifications/tests/integration/services/orchestration/cancel-and-supersede.integration.spec.js#leaves a delivery that already left, superseding the instance all the same - scenario: ATS-PFM-NOT-006-04 suite: TST-PFM-NOT-077 assertions: - >- services-platform:modules/notifications/tests/integration/services/orchestration/cancel-and-supersede.integration.spec.js#supersedes the earlier request of a definition whose scope is the occurrence, and tells the person the new one - >- services-platform:modules/notifications/tests/integration/services/orchestration/cancel-and-supersede.integration.spec.js#leaves the earlier request alone when the definition does not supersede by occurrence - >- services-platform:modules/notifications/tests/integration/services/orchestration/cancel-and-supersede.integration.spec.js#does not supersede the earlier request when the later one is itself refused evidence: - >- services-platform:modules/notifications/tests/integration/services/orchestration/cancel-and-supersede.integration.spec.js - The file and referenced assertion titles exist at the pinned commit. dependency_evidence: - >- Real: PostgreSQL with row-level security on, the real orchestrator and persistence services. Doubled: the dispatcher nudge and - >- the recording channel adapter. Never doubled: the database or the orchestrator. --- # cancel and supersede ## Verification Boundary This suite exercises the local services and prepared PostgreSQL database. API lifecycle cases use signed test contexts through the real route handler; they do not invoke the deployed gateway. ## What This Suite Proves Its cases exercise collapse matching bursts while separating other events; create a fresh item after reading or archiving; separate explicit resource scopes; retain latest contribution details and bounded lineage; serialize matching collapse identities; withdraw contributions without losing remaining work. The registered scenario bindings identify the assertions this executable file contributes. They retain individual test references so that a composite scenario does not become a claim of complete execution by one file. ## What It Does Not Prove Local outcomes do not prove deployed queues, external provider acceptance, production credentials or complete browser behavior. No fresh execution or conformance result is claimed. ## Real Dependencies and Test Doubles The notification fixtures use real PostgreSQL and module logic. Queue publication, visibility changes, nudges and installed channel adapters are recorded at their seams when the suite needs them. Signed API contexts replace the authorizer key in API suites. ## Must Not Be Doubled Database constraints, workspace policy, state guards and the service operation under test must remain real. Recording a provider or queue call must not replace the submission, claim or outcome logic being checked.