Skip to content

ATS-PFM-NOT-008Recover notification processing and retain its history: Capability Test Specification

Markdown

ATS-PFM-NOT-008

Recover notification processing and retain its history: Capability Test Specification

Markdown
  • DocumentProposed

KindAcceptance test setProduct areaPlatformModuleStaff Notifications and Association CommunicationsRevision2

Read atservices-platform ad3f6a65react-console baf6dae3

Coverage

  • Rule gap: FND-PFM-NOT-069
  • Transition covered
  • Validation gap: FND-PFM-NOT-069
  • Permission covered
  • Edge gap: FND-PFM-NOT-069
  • Failure covered
  • Boundary covered
  • Concurrency covered
  • Invariant covered
  • Interaction covered

Test Scenarios

11 scenarios proving CAP-PFM-NOT-008; 8 bound to an existing test.

01 Publish acknowledged entries and retain rejected workconcurrencyapitest
Proves
BR-CAP-PFM-NOT-008-01
Preconditions
Queue rows in two workspaces, more than one batch in one.
Steps
Compare nudged and scheduled dispatch, reject one queue publication and execute two concurrent dispatch runs.
Expected
Accepted entries publish and disappear; rejected work is retried. Claims are exclusive, and nudges visit only their selected workspace.
Data
Use only records created and owned by this suite.
Bound to
Source
services-platform:modules/notifications/tests/integration/services/dispatch/dispatch-notifications.integration.spec.js#publishes a pointer for a committed row and deletes the row
02 Recover publication interrupted before deletionfailureapitest
Proves
BR-CAP-PFM-NOT-008-02
Preconditions
Prepare a row published but not deleted.
Steps
Run the dispatcher a second time and process both items.
Expected
Recovery republishes the surviving entry but creates only one request.
Data
Use only records created and owned by this suite.
Bound to
services-platform:modules/notifications/tests/integration/services/dispatch/dispatch-notifications.integration.spec.js#leaves work for the next run when a run died between the publish and the delete, and the repeat makes nothing twice
Source
services-platform:modules/notifications/tests/integration/services/dispatch/dispatch-notifications.integration.spec.js#leaves work for the next run when a run died between the publish and the delete, and the repeat makes nothing twice
03 Make request redelivery harmlessinvariantapitest
Proves
BR-CAP-PFM-NOT-008-03
Preconditions
Prepare a request item already processed.
Steps
Deliver the identical item a second time.
Expected
No additional request, notice or delivery records are stored.
Data
Use only records created and owned by this suite.
Bound to
services-platform:modules/notifications/tests/integration/services/orchestration/orchestrate-request.integration.spec.js#recognizes a redelivered item by its record, writes nothing more and nudges the dispatcher
services-platform:modules/notifications/tests/integration/services/persistence/requests.integration.spec.js#answers the record already there for a redelivered request, unchanged, and says it wrote nothing
services-platform:modules/notifications/tests/integration/services/persistence/instances.integration.spec.js#answers the instance already there for a repeated key, unchanged, and says it created nothing
Source
services-platform:modules/notifications/tests/integration/services/orchestration/orchestrate-request.integration.spec.js#recognizes a redelivered item by its record, writes nothing more and nudges the dispatcher
04 Recover stale sending and lost delivery worktransitionapitest
Proves
BR-CAP-PFM-NOT-008-05
Preconditions
Prepare a delivery sending for 20 minutes, one sending for 5; a queued delivery whose work vanished two hours ago; an expired queue row.
Steps
Execute workspace reconciliation.
Expected
The twenty-minute send fails as ambiguous, the five-minute send remains unchanged, lost work is requeued and the stale queue entry becomes an expired request.
Data
Use only records created and owned by this suite.
Bound to
services-platform:modules/notifications/tests/integration/services/reconcile/reconcile-tenant.integration.spec.js#settles a delivery left sending past the ambiguity window failed ambiguous, and the instance with it, never resending
services-platform:modules/notifications/tests/integration/services/reconcile/reconcile-tenant.integration.spec.js#records a queue row nobody processed before its payload’s expiry as an expired request and deletes the row
services-platform:modules/notifications/tests/integration/services/reconcile/reconcile-tenant.integration.spec.js#runs the same reconcile once per tenant per night through the engine’s state machine, run in process
Source
services-platform:modules/notifications/tests/integration/services/reconcile/reconcile-tenant.integration.spec.js#settles a delivery left sending past the ambiguity window failed ambiguous, and the instance with it, never resending
05 Apply retention and partition boundariesboundaryapitest
Proves
BR-CAP-PFM-NOT-008-06
Preconditions
Prepare retained records on both sides of the thirteen-month cutoff.
Steps
Execute retention cleanup and try inserting an item into an unprepared month.
Expected
Aged records are deleted in batches, younger records survive and an insert without a matching partition fails.
Data
Use only records created and owned by this suite.
Bound to
services-platform:modules/notifications/tests/integration/services/reconcile/reconcile-tenant.integration.spec.js#deletes requests, deliveries, events, instance keys and challenges past it and keeps what is younger
services-platform:modules/notifications/tests/unit/registry-tables.spec.js#registers the instances as monthly-partitioned on created_at, thirteen months kept and two ahead
services-platform:modules/notifications/tests/integration/db/notification-instances.table.integration.spec.js#refuses a row of a month with no partition rather than absorbing it in a default partition
Source
services-platform:modules/notifications/tests/integration/services/reconcile/reconcile-tenant.integration.spec.js#computes the cutoff as thirteen calendar months before now
06 Distinguish workspace deletion from resetinteractionapitest
Proves
BR-CAP-PFM-NOT-008-07
Preconditions
Two workspaces with rows in every table.
Steps
Delete the first workspace's notification data and reset the second workspace's operational history.
Expected
Purge removes all scoped rows; reset retains configuration, preferences and usage. Both preserve another workspace's data.
Data
Use only records created and owned by this suite.
Bound to
services-platform:modules/notifications/tests/integration/services/persistence/tenant-purges.integration.spec.js#purges every table of the tenant by repeated calls and leaves nothing, then finds nothing to remove
services-platform:modules/notifications/tests/integration/services/persistence/tenant-purges.integration.spec.js#removes the operational records and leaves the configuration and the metering as they were
Source
services-platform:modules/notifications/tests/integration/services/persistence/tenant-purges.integration.spec.js#purges every table of the tenant by repeated calls and leaves nothing, then finds nothing to remove
07 Exclude sensitive values from captured normal-path logsinvariantapitest
Proves
BR-CAP-PFM-NOT-008-08
Preconditions
Prepare a capturing logger.
Steps
Process supplied body text, a link and an address while capturing pipeline logs.
Expected
Captured log entries contain none of the supplied content, links, data, addresses or credentials.
Data
Use only records created and owned by this suite.
Bound to
services-platform:modules/notifications/tests/integration/services/orchestration/logging.integration.spec.js#writes ids, keys and outcomes and never a title, a body, a link, a data value or an e-mail address
Source
services-platform:modules/notifications/tests/integration/services/orchestration/logging.integration.spec.js#writes ids, keys and outcomes and never a title, a body, a link, a data value or an e-mail address
08 Enforce notification row visibilitypermissionapitest
Proves
BR-CAP-PFM-NOT-008-09 INV-DOM-PFM-NOT-003-09
Preconditions
Notices in two workspaces.
Steps
Retrieve through the parent table, through a partition, and with no organization set.
Expected
Each workspace sees its own rows; execution without a workspace sees no scoped rows.
Data
Use only records created and owned by this suite.
Bound to
services-platform:modules/notifications/tests/unit/registry-tables.spec.js#exempts exactly the catalog among the module’s tables as a tenantless registry, with a reason
services-platform:modules/notifications/tests/unit/registry-tables.spec.js#gives every other table a tenant_id for the policy to bind
services-platform:modules/notifications/tests/integration/db/notification-instances.table.integration.spec.js#shows a tenant its own instances and not another’s, through the parent
Source
services-platform:modules/notifications/tests/unit/registry-tables.spec.js#exempts exactly the catalog among the module’s tables as a tenantless registry, with a reason
09 Detect dispatcher silencefailureunitproposed
Proves
BR-CAP-PFM-NOT-008-10
Preconditions
Synthesized notification deployment with an operations paging topic.
Steps
Inspect the configured run-count metric, fifteen-minute period, below-one threshold, missing-data handling and paging target.
Expected
The alarm treats no run or missing data as a breach and targets operations paging.
Data
Use isolated deployment configuration rather than publishing metrics to a shared environment.
Source
services-platform:modules/notifications/aws/logic/notifications-functions.lambda.ts:createDispatcherSilenceAlarm
10 Detect absent nightly reconciliationfailureunitproposed
Proves
BR-CAP-PFM-NOT-008-11
Preconditions
Synthesized notification deployment with an operations paging topic.
Steps
Inspect the schedule-count alarm with two daily evaluation periods, two required breaches, missing-data handling and paging target.
Expected
Two consecutive days below one scheduled run trigger the configured operations-paging alarm.
Data
Use isolated deployment configuration rather than publishing metrics to a shared environment.
Source
services-platform:modules/notifications/aws/logic/notifications-reconcile.lambda.ts:createNotificationsReconcileFunctions
11 Recovery does not restore withdrawn work or duplicate deliveryinteractionapiproposed
Proves
BR-CAP-PFM-NOT-008-02
Preconditions
Use a committed personal request, a lost dispatch acknowledgement and a queued delivery that is later withdrawn.
Steps
Repeat dispatch and request processing, withdraw the queued work, then run nightly reconciliation and read the personal inbox.
Expected
The occurrence has one recipient notice. Reconciliation does not send withdrawn work, and inbox applicability agrees with the retained request history.
Data
A suite-owned workspace, named staff accounts and unique occurrence keys; external adapters record attempts without shared writes.
Source
rhythm-v2-docs:specs/platform/notifications/planning/capabilities/CAP-PFM-NOT-008-keep-notifications-whole-when-part-of-the-pipeline-fails.md#frontmatter,rhythm-v2-docs:specs/platform/notifications/planning/capabilities/CAP-PFM-NOT-002-tell-people-that-something-happened-with-one-call.md#frontmatter,rhythm-v2-docs:specs/platform/notifications/planning/capabilities/CAP-PFM-NOT-006-withdraw-or-expire-a-notice-that-no-longer-applies.md#frontmatter,rhythm-v2-docs:specs/platform/notifications/planning/capabilities/CAP-PFM-NOT-007-deliver-each-notice-on-the-channels-it-may-use.md#frontmatter

The Markdown files under specs/ in rhythmsoftware/rhythm-v2-docs are the canonical source of truth. This reader is a generated, read-only projection of them.