Simulation Guide
Knowledge Guides /How to Validate Isolation, Reconnection, and Resource Release in a Multi-Session Simulation Service
Last updated: · New Horizon Digital Outsourcing Team
Multi-session simulation acceptance should answer three questions: whether a command affects only its target session, whether a reconnecting client can reassociate with the correct run state, and whether resources are released as agreed after a session ends. Exercise two independent sessions and inspect ownership of their execution contexts, logs, results, and resources. Define reconnection and cleanup policies in advance and verify them with service-side evidence.
Define Session and Initialization Boundaries
- Record a distinct session identifier, model version, input version, and initialization outcome for each run. Failed initialization must not silently reuse objects or outputs from a previous run. Record how defaults and current inputs are prioritized.
- Check consecutive runs of one model and concurrent runs of different models to ensure commands, logs, and results stay with the intended session. Shared services may be reused, but session ownership and run-data isolation must remain inspectable.
Verify Isolation Through Cross-Session Operations
- Create two generic sessions with distinguishable inputs. Keep one running while pausing, stepping, and stopping the other. For each operation, check the target session identifier, state change, and output ownership, and inspect the continuing session for unintended effects. The focus is non-interference between sessions.
- Next, let one session fail initialization or terminate and check that the other retains its execution context, logs, and results. A shared service may reuse threads or other resources. Judge acceptance against agreed ownership and isolation behavior rather than inferring session count or successful isolation directly from thread count.
Check Resource Release Against Session Ownership
- Maintain inspectable ownership records for runtime objects, queued work, and execution resources, distinguishing exclusive resources from resources still shared by other sessions. After ending one session, check that its work has stopped, its exclusive resources have been released, and shared resources still support remaining sessions. A client exit should not automatically be treated as termination of the entire service.
- Agree on cleanup completion criteria and a finite waiting period, and assess outcomes using active-session, queue, and resource records. Keep session identifiers and termination reasons on partial outputs from cancelled or failed runs. After repeated session creation and termination, check for resources no longer owned by active work; a closed window or a single memory fluctuation does not establish successful cleanup.
Check Reconnection and Repeated Commands
- In a controlled environment, check repeated run commands, repeated stops, disconnection while paused, and reconnection, with acceptable outcomes defined in advance. On reconnection, query the current service state instead of treating stale UI state as authoritative.
- Deliver the session-state contract, operation records, result labels, and known limitations so the recipient can check cancellation followed by a new run. Passing control-flow acceptance establishes run-management behavior; numerical accuracy requires separate verification.