Skip to content

ATS-PFM-ELG-010Refresh decisions and request role rechecks: Capability Test Specification

Markdown

ATS-PFM-ELG-010

Refresh decisions and request role rechecks: Capability Test Specification

Markdown
  • DocumentProposed

KindAcceptance test setProduct areaPlatformModuleEligibility, Responsibilities and AttentionRevision3

Read atservices-platform ad3f6a65react-console baf6dae3

Coverage

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

Test Scenarios

10 scenarios proving CAP-PFM-ELG-010; 6 bound to an existing test.

01 Use display-only answer cachingboundaryapitest
Proves
BR-CAP-PFM-ELG-010-01 INV-DOM-PFM-ELG-003-06
Preconditions
One expression has display and authorization uses.
Steps
Repeat both evaluations around a source-record change.
Expected
Display can repeat the prior answer and authorization reads freshly.
Data
No fixtures beyond the described setup.
Bound to
services-platform:modules/eligibility/tests/e2e/eligibility-evaluate.e2e.spec.js#answers the second display evaluation from the cache, without the change
services-platform:modules/eligibility/tests/e2e/eligibility-evaluate.e2e.spec.js#never answers an authorization evaluation from the cache
Source
services-platform:modules/eligibility/tests/e2e/eligibility-evaluate.e2e.spec.js#answers the second display evaluation from the cache, without the change
02 Invalidate answers on releaseinvariantapitest
Proves
BR-CAP-PFM-ELG-010-02
Preconditions
A display answer is already cached.
Steps
Republish and evaluate again.
Expected
The next result obtains current data.
Data
No fixtures beyond the described setup.
Bound to
services-platform:modules/eligibility/tests/e2e/eligibility-evaluate.e2e.spec.js#answers from the data again once the publish has flushed the definition’s decisions
Source
services-platform:modules/eligibility/tests/e2e/eligibility-evaluate.e2e.spec.js#publishes the definition again
03 Queue affected role subjectsinteractionapitest
Proves
BR-CAP-PFM-ELG-010-03
Preconditions
A bound role has holders and a simulation identifies gains.
Steps
Publish with the completed simulation.
Expected
Holder and gain rechecks are queued and counted in the response.
Data
No fixtures beyond the described setup.
Bound to
services-platform:modules/eligibility/tests/integration/services/population/population-run.integration.spec.js#queues a reconcile for every subject the simulation found newly eligible when the version is published
Source
services-platform:modules/eligibility/tests/integration/services/population/population-run.integration.spec.js#queues a reconcile for every subject the simulation found newly eligible when the version is published
04 Respect declared change refreshruleapitest
Proves
BR-CAP-PFM-ELG-010-04
Preconditions
Cached subjects use event-enabled and time-only conditions.
Steps
Send contact changes through the receiver for both configurations.
Expected
Event-enabled work invalidates and queues with an event result; time-only work acknowledges without changes.
Data
No fixtures beyond the described setup.
Bound to
services-platform:modules/eligibility/tests/integration/services/population/population-run.integration.spec.js#deletes the contact’s cached display decision when the change arrives through the deployed entry, as CRM sends it
services-platform:modules/eligibility/tests/integration/services/population/population-run.integration.spec.js#queues a reconcile of that contact, and answers the remote-handler contract, one result by event_id
services-platform:modules/eligibility/tests/integration/services/population/population-run.integration.spec.js#does nothing for a change a ttl-only type reads: nothing dropped, nothing queued
Source
services-platform:modules/eligibility/tests/integration/services/population/population-run.integration.spec.js#deletes the contact’s cached display decision when the change arrives through the deployed entry, as CRM sends it
05 Bound system recheck requestspermissionapinegativetest
Proves
BR-CAP-PFM-ELG-010-05
Preconditions
System staff and console callers are available.
Steps
Request 101 subjects, repeated subjects and already-pending subjects, then call from console.
Expected
Excess and console requests fail; repeated subjects queue once and pending subjects return their waiting request.
Data
No fixtures beyond the described setup.
Bound to
Source
services-platform:modules/security/tests/integration/services/dispatch/derived-assignment-reconciles.integration.spec.js#is a system route asking for the staff-only platform.eligibility.reconcile
06 Keep portal wording fresh and suspension immediaterulebrowsernegativetest
Proves
BR-CAP-PFM-ELG-010-07
Preconditions
A display answer is cached for an active use.
Steps
Edit its portal message, suspend the use and resume the unchanged plan before cache expiry.
Expected
The edit is reflected in a new answer, suspension refuses immediately and resumption may reuse the unchanged cached answer.
Data
Existing evidence fixtures provide the described setup.
Bound to
Source
react-console:acceptance/eligibility/playwright/journeys/invalidation/ELIG-ACC-0481.spec.ts#ELIG-ACC-0481
07 Refresh an answer after publicationinteractionapiproposed
Proves
BR-CAP-PFM-ELG-004-07 BR-CAP-PFM-ELG-010-02
Preconditions
A following use has a cached eligible display answer.
Steps
Publish a draft that changes the subject to ineligible and evaluate the same use again.
Expected
The next answer names the new expression and reports ineligible instead of the earlier cached answer.
Data
Run-owned records and a controlled clock where timing changes the result.
Source
services-platform:modules/eligibility/tests/integration/services/governance/publish-followers.integration.spec.js#finds every rule that inlines C at any depth, and none that pins a version of C; services-platform:modules/eligibility/tests/e2e/eligibility-evaluate.e2e.spec.js#answers from the data again once the publish has flushed the definition’s decisions
08 Keep display caching separate from authorityinteractionapiproposed
Proves
BR-CAP-PFM-ELG-008-01 BR-CAP-PFM-ELG-010-01
Preconditions
A display answer is cached before its subject changes.
Steps
Evaluate display and authorization requests before the cache expires, then repeat after expiry.
Expected
Authorization reads the changed data immediately and display refreshes at expiry; cache hits add no decision.
Data
Run-owned records and a controlled clock where timing changes the result.
Source
services-platform:modules/eligibility/tests/unit/compile-and-evaluate.spec.js#makes an indeterminate state ineligible under closed; services-platform:modules/eligibility/tests/e2e/eligibility-evaluate.e2e.spec.js#never answers an authorization evaluation from the cache
09 Queue simulation gains with release refreshinteractionapiproposed
Proves
BR-CAP-PFM-ELG-010-03 BR-CAP-PFM-ELG-011-07
Preconditions
A simulation identifies newly eligible subjects and a derived role already has holders.
Steps
Publish with the matching simulation and inspect queued role rechecks and the following use answer.
Expected
Existing holders and bounded gains are queued and the following use observes the new expression.
Data
Run-owned records and a controlled clock where timing changes the result.
Source
services-platform:modules/eligibility/tests/integration/services/population/population-run.integration.spec.js#queues a reconcile for every subject the simulation found newly eligible when the version is published; services-platform:modules/eligibility/tests/integration/services/population/population-run.integration.spec.js#refuses a publish naming a simulation of another version of the draft
10 Observe aging role rechecksinteractionapiproposed
Proves
BR-CAP-PFM-ELG-010-03 BR-CAP-PFM-ELG-012-03
Preconditions
Publication has enqueued role rechecks.
Steps
Keep one request pending beyond the alarm threshold and inspect queue-age metrics.
Expected
The queue-age series used by the alarm reflects the overdue request.
Data
Run-owned records and a controlled clock where timing changes the result.
Source
services-platform:modules/eligibility/tests/integration/services/population/population-run.integration.spec.js#queues a reconcile for every subject the simulation found newly eligible when the version is published; services-platform:modules/eligibility/tests/unit/alarm-inputs.spec.ts#reads the population run’s failure under the service its task function records it as (DEF-ELIG-0675)

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.