Skip to content

ATS-PFM-TNL-003Understand and recover a workspace build: Capability Test Specification

Markdown

ATS-PFM-TNL-003

Understand and recover a workspace build: Capability Test Specification

Markdown
  • DocumentProposed

Planning

Proves capability
CAP-PFM-TNL-003

Design

Executed by
TST-PFM-TNL-055, TST-PFM-TNL-056, TST-PFM-TNL-083

KindAcceptance test setProduct areaPlatformModuleWorkspace Lifecycle Across ApplicationsRevision3

Read atservices-platform ad3f6a65services-crm a8d1364fservices-commerce c8b66a98services-committees 36129c24services-membership 5994c270services-submissions 64236c19services-websites 5fc6823cservices-marketing d071a159rhythm-v2-docs d318a948

Coverage

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

Test Scenarios

10 scenarios proving CAP-PFM-TNL-003; 9 bound to an existing test.

01 Snapshots distinguish authorized and absent readspermissionapinegativetest
Proves
BR-CAP-PFM-TNL-003-01
Preconditions
Fixtures include a requested workspace and one without a provisioning job.
Steps
Read as staff and customer administrator, then inspect the no-job fixture.
Expected
Staff obtain named steps; customer authority is refused and the no-job read returns not found.
Data
Use the run-owned records and caller contexts created by the cited tests; use their provider and clock seams only where declared.
Bound to
services-platform:modules/tenants/tests/e2e/tenant-provisioning.e2e.spec.js#shows every step completed, and names each one for the person reading it
services-platform:modules/tenants/tests/e2e/tenant-provisioning.e2e.spec.js#may not watch the provisioning of their own tenant
services-platform:modules/tenants/tests/e2e/tenant-provisioning.e2e.spec.js#answers 404 for a tenant that was never provisioned by a request
Source
services-platform:modules/tenants/tests/e2e/tenant-provisioning.e2e.spec.js#shows every step completed, and names each one for the person reading it
02 Failed construction retains partial resourcesfailureapitest
Proves
BR-CAP-PFM-TNL-003-02
Preconditions
A participant refuses its construction step.
Steps
Run the job and inspect its workspace and snapshot.
Expected
The workspace remains provisioning failed with the recorded refusal summary.
Data
Use the run-owned records and caller contexts created by the cited tests; use their provider and clock seams only where declared.
Bound to
services-platform:modules/tenants/tests/e2e/tenant-provisioning.e2e.spec.js#leaves the tenant saying its provisioning failed, which is what makes it retryable
services-platform:modules/tenants/tests/e2e/tenant-provisioning.e2e.spec.js#says so in the snapshot too, with the failure summary the task refused with
Source
services-platform:modules/tenants/tests/e2e/tenant-provisioning.e2e.spec.js#leaves the tenant saying its provisioning failed, which is what makes it retryable
03 Recovery is limited to failed buildstransitionapinegativetest
Proves
BR-CAP-PFM-TNL-003-03
Preconditions
One build failed and another succeeded.
Steps
Request retry for each workspace.
Expected
The failed build gets a new attempt and can open; the successful build rejects retry.
Data
Use the run-owned records and caller contexts created by the cited tests; use their provider and clock seams only where declared.
Bound to
services-platform:modules/tenants/tests/e2e/tenant-provisioning.e2e.spec.js#refuses to provision a tenant again whose provisioning did not fail
Source
services-platform:modules/tenants/tests/e2e/tenant-provisioning.e2e.spec.js#answers 200 and a new job to the retry
04 Outcome handling avoids normal replayedgeapitest
Proves
BR-CAP-PFM-TNL-003-04
Preconditions
Success and failure fixtures include requester notices.
Steps
Repeat closing tasks and failure reconciliation.
Expected
The delivered fixture notice is retained without another send.
Data
Use the run-owned records and caller contexts created by the cited tests; use their provider and clock seams only where declared.
Bound to
services-platform:modules/tenants/tests/integration/services/provisioning/provisioning-notices.integration.spec.js#sends nothing more when the reconciler applies the same consequence afterwards
Source
services-platform:modules/tenants/tests/integration/services/provisioning/provisioning-notices.integration.spec.js#sends the requester one message
05 Alerts accompany requester mailruleapitest
Proves
BR-CAP-PFM-TNL-003-06
Preconditions
A successful build has an operations-channel fixture.
Steps
Inspect the alert and captured requester message.
Expected
Both channels identify the workspace and job outcome.
Data
Use the run-owned records and caller contexts created by the cited tests; use their provider and clock seams only where declared.
Bound to
services-platform:modules/tenants/tests/e2e/tenant-provisioning-alerts.e2e.spec.js#posts “Tenant ready” to the operations channel, with the message ts as the delivery’s provider reference
services-platform:modules/tenants/tests/e2e/tenant-provisioning-alerts.e2e.spec.js#tells the requester by e-mail as well: the alert is beside the notice, not instead of it
Source
services-platform:modules/tenants/tests/e2e/tenant-provisioning-alerts.e2e.spec.js#posts “Tenant ready” to the operations channel, with the message ts as the delivery’s provider reference
06 Stranded repair is repeatableinvariantapitest
Proves
BR-CAP-PFM-TNL-003-07
Preconditions
One workspace has a settled unstarted job and another a running job.
Steps
Run repair twice.
Expected
Only the stranded workspace becomes failed; its notice is handled once and the running workspace remains intact.
Data
Use the run-owned records and caller contexts created by the cited tests; use their provider and clock seams only where declared.
Bound to
services-platform:modules/tenants/tests/integration/services/provisioning/repair-stranded-provisioning.integration.spec.js#moves the stranded tenant to provisioning_failed, which makes it retryable and deletable again
services-platform:modules/tenants/tests/integration/services/provisioning/repair-stranded-provisioning.integration.spec.js#tells the staff member who asked for the tenant once, with the job’s own summary
services-platform:modules/tenants/tests/integration/lifecycle/reconciled-job-failure.integration.spec.js#moves the tenant to provisioning_failed, which is what makes it retryable and deletable again
Source
services-platform:modules/tenants/tests/integration/services/provisioning/repair-stranded-provisioning.integration.spec.js#moves the stranded tenant to provisioning_failed, which makes it retryable and deletable again
07 Ready mail links the requester to progressruleapitest
Proves
AS-JNY-PFM-TNL-001-03
Preconditions
The successful provisioning journey captures requester mail.
Steps
Inspect the captured message and repeat outcome handling.
Expected
A single handled ready message includes the job link.
Data
Use the run-owned records and caller contexts created by the cited tests; use their provider and clock seams only where declared.
Bound to
services-platform:modules/tenants/tests/integration/services/provisioning/provisioning-notices.integration.spec.js#links to the job’s own page in Rhythm HQ, so the requester can read the steps
Source
services-platform:modules/tenants/tests/integration/services/provisioning/provisioning-notices.integration.spec.js#sends the requester one message
08 Failure explanation supports staff recoveryruleapitest
Proves
AS-JNY-PFM-TNL-002-01
Preconditions
The recovery journey has a refused build.
Steps
Inspect its retained workspace and job snapshot.
Expected
The failed workspace and explanation remain available without removal of completed construction.
Data
Use the run-owned records and caller contexts created by the cited tests; use their provider and clock seams only where declared.
Bound to
services-platform:modules/tenants/tests/e2e/tenant-provisioning.e2e.spec.js#leaves the tenant saying its provisioning failed, which is what makes it retryable
services-platform:modules/tenants/tests/e2e/tenant-provisioning.e2e.spec.js#says so in the snapshot too, with the failure summary the task refused with
Source
services-platform:modules/tenants/tests/e2e/tenant-provisioning.e2e.spec.js#leaves the tenant saying its provisioning failed, which is what makes it retryable
09 Recovery opens without duplicate constructioninteractionapitest
Proves
AS-JNY-PFM-TNL-002-02
Preconditions
The recovery journey retains completed steps from its failed attempt.
Steps
Run retry through activation.
Expected
The workspace opens and already completed participant work is not repeated.
Data
Use the run-owned records and caller contexts created by the cited tests; use their provider and clock seams only where declared.
Bound to
services-platform:modules/tenants/tests/integration/services/provisioning/provision-tenant.integration.spec.js#does the missing work and not the finished work when it is provisioned again
Source
services-platform:modules/tenants/tests/integration/services/provisioning/provision-tenant.integration.spec.js#does the missing work and not the finished work when it is provisioned again
10 An unwanted failed build enters deliberate deletioninteractionapinegativeproposed
Proves
BR-CAP-PFM-TNL-003-08
Preconditions
A retained failed build contains completed participant work and is eligible for staff deletion.
Steps
Inspect its failed snapshot, request deletion and read the resulting request and workspace standing.
Expected
The failed build remains available for review until deletion is requested; the request creates a separate decision and the shorter unopened-workspace wait.
Data
Create a separate run-owned workspace for each decision branch and an unaffected comparison workspace. Use a controlled clock, paused task or injected fault at the boundary named in the scenario.
Source
rhythm-v2-docs:specs/platform/tenant-lifecycle/planning/capabilities/CAP-PFM-TNL-003-follow-a-provisioning-retry-it-and-hear-how-it-ended.md; rhythm-v2-docs:specs/platform/tenant-lifecycle/planning/capabilities/CAP-PFM-TNL-013-ask-for-a-workspace-to-be-deleted-after-a-waiting-period.md; rhythm-v2-docs:specs/platform/tenant-lifecycle/planning/capabilities/CAP-PFM-TNL-001-ask-for-a-new-workspace-and-have-every-application-build-it.md

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.