> For the complete documentation index, see [llms.txt](https://docs.mosip.io/1.2.0/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.mosip.io/1.2.0/roadmap-and-releases/releases/v1.5.0-dsl.md).

# V1.5.0-DSL

#### **Release Name:** DSL Orchestrator & Packet Creator

**Release Version:** 1.5.0

**Release Type:** Minor Release

**Release Date:** <mark style="color:red;">**Coming Soon!**</mark>

### **Overview**

This minor release of DSL Orchestrator & Packet Creator v1.5.0 is a maintenance release focused on improving framework scalability, execution performance, maintainability, and operational reliability. This release introduces major framework enhancements, including support for thread-safe execution with up to 20 concurrent threads, migration of scenario definitions to Gherkin syntax, and optimisation of packet creation, encryption, template generation, and file processing workflows to improve execution speed and resource utilization.

Architecture and code quality improvements include a standardized step execution lifecycle, centralized variable resolution and context management, enhanced caching for masterdata and authentication resources, service modularization, removal of legacy and unused code, and improved Swagger and feature documentation.

Several performance and reliability fixes have been implemented to improve parallel execution stability, memory management, packet processing efficiency, scenario context propagation, and logging capabilities. Security and observability have also been enhanced through sensitive data masking and centralized log storage integration with MinIO, improving overall execution traceability and operational visibility.

Additionally, the release includes several new DSL scenarios, multiple performance optimizations, bug fixes, and framework refactoring to provide a more stable and efficient automation platform.

### **Major Highlights / Key Features**

#### Parallel Execution & Performance

* Optimized the framework to support thread-safe execution with up to **20 concurrent threads**.
* Improved packet creation performance and execution throughput.
* Enhanced suite initialization and report generation.
* Introduced execution-level caching for:
  * Master data
  * Authentication resources
  * Frequently accessed API responses
* Reduced redundant backend API calls and improved regression execution time.

#### Framework Architecture & Maintainability

* Migrated DSL scenario definitions from JSON to **Cucumber Gherkin** syntax.
* Introduced a standardized step execution lifecycle consisting of:
  * Bind
  * Prepare
  * Execute
  * Assert
  * Publish
* Implemented a unified variable resolution framework supporting global, scenario, and step-level contexts.
* Refactored Data Provider and Packet Creator components into modular services.
* Removed legacy dependencies, obsolete code, and unused artifacts.

#### Reliability & Resource Optimization

* Fixed memory leak issues across Packet Creator and Test Data Provider.
* Optimized packet management workflows and temporary resource handling.
* Improved parallel execution stability through thread-safe context isolation.
* Enhanced packet processing efficiency and resource cleanup.

#### Reporting, Logging & Security

* Introduced centralized API logging for improved execution traceability.
* Enhanced DSL TestNG reports with improved UI and navigation.
* Implemented automatic masking of sensitive information including:
  * Passwords
  * Tokens
  * Secrets
  * API Keys
* Improved centralized execution log storage and observability.

#### DSL Scenario Coverage

* Added **10 new DSL scenarios** covering:
  * Registration
  * UIN generation
  * Demographic updates
  * Biometric updates **(including selective fingerprint/iris updates)**
  * Delegated authentication
  * Multi-step update workflows
* Expanded negative and edge-case validations across registration and update journeys.
* Refer [this link](https://github.com/mosip/mosip-automation-tests/blob/release-1.5.x/mosip-acceptance-tests/ivv-orchestrator/src/main/resources/config/scenarios.feature) to know more about all DSL scenario details

### **Repositories Released**

| Repository                 | Version                                                                      |
| -------------------------- | ---------------------------------------------------------------------------- |
| **mosip-automation-tests** | [v1.5.0](https://github.com/mosip/mosip-automation-tests/tree/release-1.5.x) |

### Stories Released

<table><thead><tr><th width="156.49609375">JIRA</th><th width="156.296875">Feature</th><th>Summary</th></tr></thead><tbody><tr><td><a href="https://mosip.atlassian.net/browse/MOSIP-44942">MOSIP-44942</a></td><td><strong>Memory Optimization</strong></td><td>Identified and resolved memory leak issues in Packet Creator and Test Data Provider components. Optimized object lifecycle management, caching behavior, and resource cleanup mechanisms to reduce memory consumption during long-running and parallel executions. These improvements enhance application stability, improve garbage collection efficiency, and support higher execution loads without memory degradation.</td></tr><tr><td><a href="https://mosip.atlassian.net/browse/MOSIP-44952">MOSIP-44952</a></td><td><strong>Packet Manager Service Optimization</strong></td><td>Refactored the Packet Manager Service to eliminate redundant processing and streamline packet creation workflows. Improved temporary file handling, packet metadata management, and cleanup operations through centralized utilities and safer resource management. These changes reduce unnecessary execution overhead, improve reliability, and enhance overall packet processing efficiency.</td></tr><tr><td><a href="https://mosip.atlassian.net/browse/MOSIP-45025">MOSIP-45025</a></td><td><strong>Centralized API Logging</strong></td><td>Implemented a centralized API logging framework to capture all internal API interactions between Packet Creator, Data Provider, and backend services. API request and response details are now consolidated and published within the TestNG report, providing improved execution traceability, easier debugging, and enhanced visibility into backend service interactions during test execution.</td></tr><tr><td><a href="https://mosip.atlassian.net/browse/MOSIP-45028">MOSIP-45028</a></td><td><strong>Test Report Enhancement</strong></td><td>Enhanced the DSL Scenarios Test Report with improved UI/UX, making execution results easier to navigate and analyze. Report layouts, visual presentation, and content organization were refined to improve readability, enabling faster identification of test outcomes, failures, and execution details.</td></tr><tr><td><a href="https://mosip.atlassian.net/browse/MOSIP-45029">MOSIP-45029</a></td><td><strong>Scenario Metadata Standardization</strong></td><td>Updated step metadata definitions in scenarios to ensure descriptions, input parameters, and return values are consistently aligned with their corresponding actions. This enhancement improves scenario documentation, usability, and maintainability while providing clearer guidance for scenario authors and reviewers.</td></tr><tr><td><a href="https://mosip.atlassian.net/browse/MOSIP-45035">MOSIP-45035</a></td><td><strong>Codebase Cleanup</strong></td><td>Performed comprehensive code cleanup across mosip-acceptance-tests, mosipTestDataProvider, and mosip-packet-creator by removing commented code, obsolete documentation, and unused artifacts. This improves code readability, reduces maintenance overhead, and helps maintain a cleaner and more consistent codebase.</td></tr><tr><td><a href="https://mosip.atlassian.net/browse/MOSIP-45041">MOSIP-45041</a></td><td><strong>Orchestrator Performance Optimization</strong></td><td>Optimized the DSL Orchestrator by streamlining suite initialization, improving parallel execution handling, and reducing pre-execution overhead. Report generation and loading mechanisms were also enhanced to provide faster access to execution results, improving overall framework responsiveness and user experience.</td></tr><tr><td><a href="https://mosip.atlassian.net/browse/MOSIP-30294">MOSIP-30294]</a></td><td><strong>Gherkin-Based Scenario Definitions</strong></td><td>Migrated scenario definitions from JSON format to standard Cucumber Gherkin syntax, improving readability, maintainability, and collaboration between technical and non-technical stakeholders. The new format provides a more structured and intuitive approach to authoring, reviewing, and documenting test scenarios.</td></tr><tr><td><a href="https://mosip.atlassian.net/browse/MOSIP-45060">MOSIP-45060</a></td><td><strong>Sensitive Data Masking</strong></td><td>Implemented automatic masking of secrets, tokens, passwords, API keys, and other sensitive credentials within DSL TestNG HTML reports, including outbound internal API request and response logs. This enhancement strengthens security and compliance by preventing accidental exposure of confidential information while maintaining execution traceability and debugging capabilities.</td></tr><tr><td><a href="https://mosip.atlassian.net/browse/MOSIP-45073">MOSIP-45073</a></td><td><strong>Master Data and Authentication Caching</strong></td><td>Introduced execution-level caching for frequently accessed master data and authentication resources to eliminate repeated calls to the same MOSIP services during full DSL regression runs. Cached data is reused throughout the execution and automatically cleared upon completion, significantly reducing API traffic, improving performance, and accelerating large-scale regression test execution.</td></tr><tr><td><a href="https://mosip.atlassian.net/browse/MOSIP-45077">MOSIP-45077</a></td><td><strong>Standardized Step Execution Lifecycle</strong></td><td>Introduced a centralized step execution framework with a standardized lifecycle pipeline comprising bind, prepare, execute, assert, and publish phases. This enhancement improves consistency across DSL steps, simplifies extensibility, reduces code duplication, and provides a more maintainable foundation for future step implementations.</td></tr><tr><td><a href="https://mosip.atlassian.net/browse/MOSIP-45078">MOSIP-45078</a></td><td><strong>Unified Variable Resolution Framework</strong></td><td>Implemented a centralized DSL parameter resolution mechanism with a scoped variable store supporting global, scenario, and step-level contexts. All parameters are now resolved consistently before step execution, improving variable management, reducing duplication, and providing better validation, maintainability, and execution reliability across DSL scenarios.</td></tr><tr><td><a href="https://mosip.atlassian.net/browse/MOSIP-45079">MOSIP-45079</a></td><td><strong>Parallel Execution Optimization</strong></td><td>Optimized mosipTestDataProvider and mosip-packet-creator for large-scale parallel DSL execution through thread-safe authentication context isolation, dedicated caching mechanisms, lazy-loading of biometric resources, and modular component refactoring. These enhancements improve scalability, reduce resource contention, accelerate execution, and increase overall maintainability and stability under concurrent workloads.</td></tr><tr><td><a href="https://mosip.atlassian.net/browse/MOSIP-45079">MOSIP-45079</a></td><td><strong>Data Provider Refactoring</strong></td><td>Refactored the Data Provider architecture to improve maintainability, scalability, and execution reliability. Enhancements include thread-safe context isolation, dedicated master data caching, removal of legacy Anguli dependencies, and decomposition of large monolithic classes into focused, reusable components, resulting in cleaner code and improved parallel execution performance.</td></tr><tr><td><a href="https://mosip.atlassian.net/browse/MOSIP-45184">MOSIP-45184</a></td><td><strong>API Response Caching</strong></td><td>Implemented caching for frequently accessed GET API responses that are repeatedly invoked across DSL scenarios. Cached responses are reused throughout execution to reduce redundant backend calls, improve test execution performance, lower service load, and enhance overall framework efficiency during regression runs.</td></tr></tbody></table>

### **Bug Fixes**

<table><thead><tr><th width="180.0390625">Bug ID</th><th>Description</th></tr></thead><tbody><tr><td><a href="https://mosip.atlassian.net/browse/MOSIP-42810"><strong>MOSIP-42810</strong></a></td><td>Fixed an issue where DSL generated additional resident credentials during credential movement validation. DSL was calling the Resident Credential API to retrieve a credentialId, which internally created a new credential for the resident. As a result, DSL validated the status of the newly generated credential instead of the original IDA-issued credential, introducing unnecessary load on the environment. The fix ensures DSL validates the correct credential movement without generating additional credentials.</td></tr><tr><td><a href="https://mosip.atlassian.net/browse/MOSIP-37060"><strong>MOSIP-37060</strong></a></td><td>Fixed an issue where <strong>Scenario_160</strong> and <strong>Scenario_75</strong> failed with the error <strong>"RPR-PKR-FAILED-002, Packet Decryption Failed"</strong> during packet processing. The fix ensures proper packet encryption and decryption handling, preventing packet processing failures caused by decryption errors.</td></tr><tr><td><a href="https://mosip.atlassian.net/browse/MOSIP-45233"><strong>MOSIP-45233</strong></a></td><td>Fixed an issue in DSL where configuration parameters were validated using hardcoded values retrieved from the <strong>Actuator</strong> /env endpoint. The hardcoded approach reduced flexibility and caused maintenance challenges when configuration values changed across environments. The fix introduces dynamic configuration validation, ensuring DSL retrieves and validates the required parameters without relying on hardcoded values.</td></tr></tbody></table>

### **Known Issues**

<table><thead><tr><th width="194.453125">Bug ID</th><th>Description</th></tr></thead><tbody><tr><td><a href="https://mosip.atlassian.net/browse/MOSIP-39352"><strong>MOSIP-39352</strong></a></td><td>In <strong>Scenarios 22, 23, 24, 83, and 161</strong>, after completing registration and receiving UIN, <strong>bio eSignet authentication using face fails with error IDA-MLC-009</strong>.</td></tr><tr><td><a href="https://mosip.atlassian.net/browse/MOSIP-41695"><strong>MOSIP-41695</strong></a></td><td>In <strong>Scenario_89</strong>, when biometric image quality remains below the threshold even after maximum correction attempts, the packet should move to <strong>REJECTED</strong> status but instead remains stuck in <strong>Paused &#x26; Request Additional Info</strong>.</td></tr><tr><td><a href="https://mosip.atlassian.net/browse/MOSIP-41699"><strong>MOSIP-41699</strong></a></td><td>In <strong>Scenario_76</strong>, a packet created with <strong>only supervisor biometrics and without operator biometrics</strong> is incorrectly marked as <strong>REGISTERED</strong> instead of the expected <strong>PROCESSED</strong> status.</td></tr><tr><td><a href="https://mosip.atlassian.net/browse/MOSIP-41694"><strong>MOSIP-41694</strong></a></td><td>In <strong>Scenario_108</strong>, the child packet gets <strong>stuck or rejected before the parent packet verification completes</strong>, whereas it should be rejected only if the parent packet is rejected.</td></tr><tr><td><a href="https://mosip.atlassian.net/browse/MOSIP-43847"><strong>MOSIP-43847</strong></a></td><td>In <strong>Scenario_144</strong>, the machine is unmapped before generating the offline packet. Instead of failing <strong>CMD validation</strong>, the packet validation itself fails earlier due to incorrect validation logic.</td></tr><tr><td><a href="https://mosip.atlassian.net/browse/MOSIP-44593"><strong>MOSIP-44593</strong></a></td><td>In <strong>Scenario_157</strong>, registration is performed on a <strong>declared holiday</strong>. The packet should fail CMD validation and move to <strong>REREGISTER</strong>, but it is processed successfully with RID status <strong>PROCESSED</strong>.</td></tr><tr><td><a href="https://mosip.atlassian.net/browse/MOSIP-44556"><strong>MOSIP-44556</strong></a></td><td>In <strong>Scenario_158</strong>, a packet created using a <strong>deactivated machine</strong> should fail during <strong>VALIDATE_PACKET</strong>, but instead moves to <strong>REPROCESS</strong>.</td></tr><tr><td><a href="https://mosip.atlassian.net/browse/MOSIP-35360"><strong>MOSIP-35360</strong></a></td><td>In <strong>Scenario_178</strong>, a resident attempts to update biometrics using an <strong>unregistered resident’s biometrics</strong>. Instead of failing ABIS matching and moving to <strong>Manual Adjudication</strong>, the system incorrectly updates biometrics successfully.</td></tr><tr><td><a href="https://mosip.atlassian.net/browse/MOSIP-41109"><strong>MOSIP-41109</strong></a></td><td>In <strong>Scenarios 194, 198, 199, 200, 201, 202, 203, 204, 208, 209, and 210</strong>, the <strong>rid/check-status API returns “RID not found”</strong> for CRVS packets even though the RID exists in the database.</td></tr><tr><td><a href="https://mosip.atlassian.net/browse/MOSIP-42426"><strong>MOSIP-42426</strong></a></td><td>In <strong>Scenarios 195 and 212</strong>, updating resident details using <strong>VID</strong> fails during IDRepo draft update with <strong>IDR-IDC-007 (No records found for RID)</strong>, causing the update process to fail.</td></tr><tr><td><a href="https://mosip.atlassian.net/browse/MOSIP-41701"><strong>MOSIP-41701</strong></a></td><td>In <strong>Scenario_205</strong>, registration performed using an <strong>inactive user</strong> is incorrectly processed successfully instead of being rejected and marked as <strong>FAILED</strong>.</td></tr><tr><td><a href="https://mosip.atlassian.net/browse/MOSIP-44591"><strong>MOSIP-44591</strong></a></td><td>In <strong>Scenario_214</strong>, a differently abled resident performs <strong>biometric delegated authentication using face modality</strong>, but authentication fails due to a <strong>partner registration error</strong>.</td></tr><tr><td><a href="https://mosip.atlassian.net/browse/MOSIP-44580"><strong>MOSIP-44580</strong></a></td><td>In <strong>Scenario_221</strong>, Resident 2 attempts biometric update using Resident 1’s biometric data. Instead of rejecting the packet due to duplication or mismatch, the packet is <strong>processed successfully</strong>.</td></tr><tr><td><a href="https://mosip.atlassian.net/browse/MOSIP-44548"><strong>MOSIP-44548</strong></a></td><td>In <strong>Scenario_229</strong>, a packet created with an <strong>invalid gender value</strong> should fail during <strong>VALIDATE_PACKET</strong>, but the system processes it successfully and RID status is shown as <strong>PROCESSED</strong>.</td></tr><tr><td><a href="https://mosip.atlassian.net/browse/MOSIP-45107"><strong>MOSIP-45107</strong></a></td><td>DSL allows packet creation with a future Date of Birth (DOB); packet is processed successfully in Scenario 149</td></tr><tr><td><a href="https://mosip.atlassian.net/browse/MOSIP-45109"><strong>MOSIP-45109</strong></a></td><td>Packet with Old ID Schema Version Fails at Packet Validation Stage in <strong>Scenario 237</strong></td></tr></tbody></table>

### **Documentation**

* **Build & Setup:** [mosip-automation-tests/README.md at release-1.5.x · mosip/mosip-automation-tests](https://github.com/mosip/mosip-automation-tests/blob/release-1.5.x/README.md)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.mosip.io/1.2.0/roadmap-and-releases/releases/v1.5.0-dsl.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
