--- id: ATS-PFM-MTD-015 scope: CAP-PFM-MTD-015 product_area: platform module: metadata revision: 2 status: proposed source_sha: services-platform: ad3f6a6582843008ed0f5a17b131878d15829af1 react-console: baf6dae382d6f41dce976c7f848667ccc37e076f scenarios: - id: ATS-PFM-MTD-015-01 title: Committed writes and rollback have different event effects level: api proves: - BR-CAP-PFM-MTD-015-01 - INV-DOM-PFM-MTD-005-10 preconditions: Valid record operations and a rejected write are available. steps: - do: 'Create, edit and perform lifecycle actions, then roll back or reject a write.' provenance: test source: >- services-platform:modules/custom-objects/tests/integration/services/persistence/custom-object-records.events.integration.spec.js#publishes nothing when the transaction that wrote the record rolls back, in the ledger or the queue expected: Committed operations leave their event and waiting work while failed transactions leave neither. negative: true data_needs: Valid record operations and a rejected write are available. bound_to: - >- services-platform:modules/custom-objects/tests/integration/services/persistence/custom-object-records.events.integration.spec.js#writes exactly one ledger row, objects.record.created - >- services-platform:modules/custom-objects/tests/integration/services/persistence/custom-object-records.events.integration.spec.js#publishes nothing when the transaction that wrote the record rolls back, in the ledger or the queue - >- services-platform:modules/custom-objects/tests/e2e/business-events.e2e.spec.js#leaves no event for a create the API refuses - >- services-platform:modules/associations/tests/integration/services/persistence/associations.events.integration.spec.js#publishes objects.association.deleted for a delete, with the association as it was - TST-PFM-MTD-064 - TST-PFM-MTD-048 - TST-PFM-MTD-043 provenance: test source: >- services-platform:modules/custom-objects/tests/integration/services/persistence/custom-object-records.events.integration.spec.js#publishes nothing when the transaction that wrote the record rolls back, in the ledger or the queue category: invariant assertions: - expect: Committed operations leave their event and waiting work while failed transactions leave neither. provenance: test source: >- services-platform:modules/custom-objects/tests/integration/services/persistence/custom-object-records.events.integration.spec.js#publishes nothing when the transaction that wrote the record rolls back, in the ledger or the queue - id: ATS-PFM-MTD-015-02 title: Update payloads identify changed keys level: api proves: - BR-CAP-PFM-MTD-015-02 preconditions: A boat has several property values. steps: - do: Change two properties and inspect its update event. provenance: test source: >- services-platform:modules/custom-objects/tests/integration/services/persistence/custom-object-records.events.integration.spec.js#publishes objects.record.updated naming the properties whose value changed, sorted expected: The event identifies the record and actor and lists the changed property keys in sorted order. negative: false data_needs: A boat has several property values. bound_to: - >- services-platform:modules/custom-objects/tests/integration/services/persistence/custom-object-records.events.integration.spec.js#carries the declared payload: the identifiers, the number with its prefix, the display name and the state - >- services-platform:modules/custom-objects/tests/integration/services/persistence/custom-object-records.events.integration.spec.js#publishes objects.record.updated naming the properties whose value changed, sorted - >- services-platform:modules/custom-objects/tests/e2e/business-events.e2e.spec.js#names the signed caller as its actor, the one the record names as its creator - TST-PFM-MTD-064 - TST-PFM-MTD-048 provenance: test source: >- services-platform:modules/custom-objects/tests/integration/services/persistence/custom-object-records.events.integration.spec.js#publishes objects.record.updated naming the properties whose value changed, sorted category: rule assertions: - expect: The event identifies the record and actor and lists the changed property keys in sorted order. provenance: test source: >- services-platform:modules/custom-objects/tests/integration/services/persistence/custom-object-records.events.integration.spec.js#publishes objects.record.updated naming the properties whose value changed, sorted - id: ATS-PFM-MTD-015-03 title: No-op mutations do not announce new facts level: api proves: - BR-CAP-PFM-MTD-015-03 preconditions: A record and relationship already have their current values. steps: - do: 'Repeat property and publication values, change only external identity and update link notes.' provenance: test source: >- services-platform:modules/custom-objects/tests/integration/services/persistence/custom-object-records.events.integration.spec.js#publishes nothing for an update that changes no property’s value expected: No new business event is appended for these cases. negative: false data_needs: A record and relationship already have their current values. bound_to: - >- services-platform:modules/custom-objects/tests/integration/services/persistence/custom-object-records.events.integration.spec.js#publishes nothing for an update that changes no property’s value - >- services-platform:modules/custom-objects/tests/integration/services/persistence/custom-object-records.events.integration.spec.js#publishes nothing for an update of the external id alone, a system column - >- services-platform:modules/custom-objects/tests/integration/services/persistence/custom-object-records.events.integration.spec.js#publishes nothing for a publication to the state the record is in - >- services-platform:modules/associations/tests/integration/services/persistence/associations.events.integration.spec.js#publishes nothing for an update of its other fields - TST-PFM-MTD-064 - TST-PFM-MTD-043 provenance: test source: >- services-platform:modules/custom-objects/tests/integration/services/persistence/custom-object-records.events.integration.spec.js#publishes nothing for an update that changes no property’s value category: edge assertions: - expect: No new business event is appended for these cases. provenance: test source: >- services-platform:modules/custom-objects/tests/integration/services/persistence/custom-object-records.events.integration.spec.js#publishes nothing for an update that changes no property’s value - id: ATS-PFM-MTD-015-04 title: Dispatch retains work until destinations accept level: api proves: - BR-CAP-PFM-MTD-015-04 preconditions: A ledger event has one or more interested destinations. steps: - do: 'Dispatch with acceptance and with a refused send, then dispatch an unwanted event.' provenance: test source: >- services-platform:modules/custom-objects/tests/integration/services/dispatch/business-events.integration.spec.js#keeps its queue row, claimed, for the next run to offer again expected: >- Accepted work is removed, refused work remains retryable and the ledger fact is retained; unwanted work produces no message. negative: true data_needs: A ledger event has one or more interested destinations. bound_to: - >- services-platform:modules/custom-objects/tests/integration/services/dispatch/business-events.integration.spec.js#sends one message per destination of the event: the native subscriber and the router - >- services-platform:modules/custom-objects/tests/integration/services/dispatch/business-events.integration.spec.js#keeps the ledger row: the fact outlives its delivery - >- services-platform:modules/custom-objects/tests/integration/services/dispatch/business-events.integration.spec.js#keeps its queue row, claimed, for the next run to offer again - TST-PFM-MTD-056 provenance: test source: >- services-platform:modules/custom-objects/tests/integration/services/dispatch/business-events.integration.spec.js#keeps its queue row, claimed, for the next run to offer again category: failure assertions: - expect: >- Accepted work is removed, refused work remains retryable and the ledger fact is retained; unwanted work produces no message. provenance: test source: >- services-platform:modules/custom-objects/tests/integration/services/dispatch/business-events.integration.spec.js#keeps its queue row, claimed, for the next run to offer again - id: ATS-PFM-MTD-015-05 title: Delivery retries only the failed destination level: api proves: - BR-CAP-PFM-MTD-015-05 preconditions: A consumer receives multiple destination messages. steps: - do: Accept one and refuse another. provenance: test source: >- services-platform:modules/custom-objects/tests/integration/services/dispatch/business-events.integration.spec.js#answers the one message whose destination refused, so SQS offers that one again expected: Only the failed message is reported for redelivery and destination contracts use the appropriate shape. negative: true data_needs: A consumer receives multiple destination messages. bound_to: - >- services-platform:modules/custom-objects/tests/integration/services/dispatch/business-events.integration.spec.js#hands the native subscriber the envelope itself - >- services-platform:modules/custom-objects/tests/integration/services/dispatch/business-events.integration.spec.js#hands the router its contract: version 1, the stream, the envelope - >- services-platform:modules/custom-objects/tests/integration/services/dispatch/business-events.integration.spec.js#answers the one message whose destination refused, so SQS offers that one again - TST-PFM-MTD-056 provenance: test source: >- services-platform:modules/custom-objects/tests/integration/services/dispatch/business-events.integration.spec.js#answers the one message whose destination refused, so SQS offers that one again category: failure assertions: - expect: >- Only the failed message is reported for redelivery and destination contracts use the appropriate shape. provenance: test source: >- services-platform:modules/custom-objects/tests/integration/services/dispatch/business-events.integration.spec.js#answers the one message whose destination refused, so SQS offers that one again - id: ATS-PFM-MTD-015-06 title: Cascade announcements retain dependency order level: api proves: - BR-CAP-PFM-MTD-015-07 preconditions: A deletion affects a linked cascade. steps: - do: Delete and inspect events. provenance: test source: >- services-platform:modules/custom-objects/tests/integration/services/persistence/custom-object-records.events.integration.spec.js#publishes the deletion of the record a cascade takes, with its own object’s number, and the association’s expected: Every dependent link and record deletion is announced before its owner deletion. negative: false data_needs: A deletion affects a linked cascade. bound_to: - >- services-platform:modules/custom-objects/tests/integration/services/persistence/custom-object-records.events.integration.spec.js#publishes objects.record.deleted with the record as it was - >- services-platform:modules/custom-objects/tests/integration/services/persistence/custom-object-records.events.integration.spec.js#publishes the deletion of the record a cascade takes, with its own object’s number, and the association’s - TST-PFM-MTD-064 provenance: test source: >- services-platform:modules/custom-objects/tests/integration/services/persistence/custom-object-records.events.integration.spec.js#publishes the deletion of the record a cascade takes, with its own object’s number, and the association’s category: interaction assertions: - expect: Every dependent link and record deletion is announced before its owner deletion. provenance: test source: >- services-platform:modules/custom-objects/tests/integration/services/persistence/custom-object-records.events.integration.spec.js#publishes the deletion of the record a cascade takes, with its own object’s number, and the association’s - id: ATS-PFM-MTD-015-07 title: Invalid retention cannot run a sweep level: api proves: - BR-CAP-PFM-MTD-015-09 preconditions: The ledger exists. steps: - do: Request a zero-day retention sweep. provenance: test source: >- services-platform:modules/custom-objects/tests/integration/services/persistence/business-events.integration.spec.js#refuses a retention shorter than a day expected: The sweep refuses the duration. negative: true data_needs: The ledger exists. bound_to: - >- services-platform:modules/custom-objects/tests/integration/services/persistence/business-events.integration.spec.js#refuses a retention shorter than a day - TST-PFM-MTD-058 provenance: test source: >- services-platform:modules/custom-objects/tests/integration/services/persistence/business-events.integration.spec.js#refuses a retention shorter than a day category: validation assertions: - expect: The sweep refuses the duration. provenance: test source: >- services-platform:modules/custom-objects/tests/integration/services/persistence/business-events.integration.spec.js#refuses a retention shorter than a day - id: ATS-PFM-MTD-015-08 title: A committed cascade leaves ordered delivery facts category: interaction level: api exercises: - CAP-PFM-MTD-015 - CAP-PFM-MTD-013 - CAP-PFM-MTD-012 - CAP-PFM-MTD-018 - CAP-PFM-MTD-019 proves: - BR-CAP-PFM-MTD-015-01 - BR-CAP-PFM-MTD-015-07 - BR-CAP-PFM-MTD-013-06 preconditions: A custom root reaches dependent records through cascading links. steps: - do: 'Delete the root in a transaction, inspect ledger order and roll back a second comparable deletion.' provenance: proposed source: &ref_0 - >- services-platform:modules/custom-objects/tests/integration/services/persistence/custom-object-records.events.integration.spec.js#publishes nothing when the transaction that wrote the record rolls back, in the ledger or the queue - >- services-platform:modules/custom-objects/tests/integration/services/persistence/custom-object-records.events.integration.spec.js#publishes the deletion of the record a cascade takes, with its own object’s number, and the association’s - >- services-platform:modules/custom-objects/tests/integration/services/persistence/custom-object-records.integration.spec.js#writes every dependant’s event before the record it depended on: the associations, then the cascade deepest first (B1) expected: Compare ledger and queue facts with record and link outcomes. negative: false data_needs: A custom root reaches dependent records through cascading links. bound_to: [] provenance: proposed source: *ref_0 assertions: - expect: Compare ledger and queue facts with record and link outcomes. provenance: proposed source: *ref_0 evidence: - >- services-platform at ad3f6a6582843008ed0f5a17b131878d15829af1: the business event specs named in each scenario. - >- Codex testing back-fill: pinned capability, domain object, state model and workflow obligations reviewed; existing bound test files and exact case titles checked. coverage: rule: covered transition: 'gap: FND-PFM-MTD-077' validation: covered permission: 'gap: FND-PFM-MTD-077' edge: covered failure: covered boundary: 'gap: FND-PFM-MTD-077' concurrency: 'gap: FND-PFM-MTD-077' invariant: covered interaction: covered coverage_obligations: - rule: BR-CAP-PFM-MTD-015-01 scenarios: - ATS-PFM-MTD-015-01 - ATS-PFM-MTD-015-08 finding: null provenance: documented source: >- specs/platform/metadata/planning/capabilities/CAP-PFM-MTD-015-announce-every-custom-record-and-link-change-to-the-rest-of.md - rule: BR-CAP-PFM-MTD-015-02 scenarios: - ATS-PFM-MTD-015-02 finding: null provenance: documented source: >- specs/platform/metadata/planning/capabilities/CAP-PFM-MTD-015-announce-every-custom-record-and-link-change-to-the-rest-of.md - rule: BR-CAP-PFM-MTD-015-03 scenarios: - ATS-PFM-MTD-015-03 finding: null provenance: documented source: >- specs/platform/metadata/planning/capabilities/CAP-PFM-MTD-015-announce-every-custom-record-and-link-change-to-the-rest-of.md - rule: BR-CAP-PFM-MTD-015-04 scenarios: - ATS-PFM-MTD-015-04 finding: null provenance: documented source: >- specs/platform/metadata/planning/capabilities/CAP-PFM-MTD-015-announce-every-custom-record-and-link-change-to-the-rest-of.md - rule: BR-CAP-PFM-MTD-015-05 scenarios: - ATS-PFM-MTD-015-05 finding: null provenance: documented source: >- specs/platform/metadata/planning/capabilities/CAP-PFM-MTD-015-announce-every-custom-record-and-link-change-to-the-rest-of.md - rule: BR-CAP-PFM-MTD-015-06 scenarios: [] finding: FND-PFM-MTD-077 provenance: documented source: >- specs/platform/metadata/planning/capabilities/CAP-PFM-MTD-015-announce-every-custom-record-and-link-change-to-the-rest-of.md - rule: BR-CAP-PFM-MTD-015-07 scenarios: - ATS-PFM-MTD-015-06 - ATS-PFM-MTD-015-08 finding: null provenance: documented source: >- specs/platform/metadata/planning/capabilities/CAP-PFM-MTD-015-announce-every-custom-record-and-link-change-to-the-rest-of.md - rule: BR-CAP-PFM-MTD-015-09 scenarios: - ATS-PFM-MTD-015-07 finding: null provenance: documented source: >- specs/platform/metadata/planning/capabilities/CAP-PFM-MTD-015-announce-every-custom-record-and-link-change-to-the-rest-of.md interactions: - with: CAP-PFM-MTD-013 scenarios: - ATS-PFM-MTD-015-08 finding: null provenance: proposed source: >- specs/platform/metadata/planning/capabilities/CAP-PFM-MTD-015-announce-every-custom-record-and-link-change-to-the-rest-of.md --- # Deliver Committed Record and Link Events: Capability Test Specification ## Coverage - Obligation 01: 2 scenarios cite this obligation. - Obligation 02: 1 scenario cite this obligation. - Obligation 03: 1 scenario cite this obligation. - Obligation 04: 1 scenario cite this obligation. - Obligation 05: 1 scenario cite this obligation. - Obligation 06: The coverage finding records the missing scenario. - Obligation 07: 2 scenarios cite this obligation. - Obligation 09: 1 scenario cite this obligation. Category coverage identifies the kind of proof present. Detailed transition, permission and invariant obligations and unbound proposals remain in the coverage finding until their individual cases are accounted for. ## Interactions With Related Capabilities Only the committed cascade leaves ordered deletion work. The structured interaction rows identify the related capabilities exercised and any remaining gap. Cross-capability workflow seams remain subject to the detailed coverage audit.