SD-2717, SD-2715: Don't refer to DCSA errorCode page

[HenrikHL]

User description

[SD-1715[(https://dcsa.atlassian.net/browse/SD-2715): Don't refer to DCSA errorCode page
SD-2717: Don't refer to DCSA errorCode page

Removing DCSA errorCode page link and changing the description to be implementer specific

---

PR Type

Documentation

---

Description

• Remove DCSA error code page reference from all API specs

• Update error code descriptions to be implementer-specific

• Add note about failed DCSA standardization attempt

• Standardize error code documentation across 9 API specification files

---

Diagram Walkthrough

flowchart LR
  A["DCSA Standard Error Codes Reference"] -->|Remove Link| B["Implementer-Specific Error Codes"]
  C["Standardized Error Code Ranges"] -->|Replace with| D["Implementer Maintains Codes"]
  E["9 API Specification Files"] -->|Update| F["Consistent Error Documentation"]

Loading

File Walkthrough

Relevant files

Documentation

9 files BKG_v2.0.4.yaml Update error code description and remove DCSA link              +2/-6      CS_v1.0.2.yaml Update error code description and remove DCSA link              +2/-6      EBL_v3.0.3.yaml Update error code description and remove DCSA link              +2/-6      EBL_END_v3.0.3.yaml Update error code description and remove DCSA link              +2/-6      EBL_ISS_v3.0.3.yaml Update error code description and remove DCSA link              +2/-6      EBL_SUR_v3.0.3.yaml Update error code description and remove DCSA link              +2/-6      OVS_v3.0.2.yaml Reformat and update error code description                              +4/-1      OVS_HUB_TER_v1.0.0.yaml Update error code description and remove DCSA link              +2/-6      EBL_PINT_v3.0.0.yaml Update error code description and remove DCSA link              +2/-6

---

[qodo-code-review]

PR Compliance Guide 🔍

Below is a summary of compliance checks for this PR:

Security Compliance
🟢	No security concerns identified No security vulnerabilities detected by AI analysis. Human verification advised for critical code.
Ticket Compliance
🟢	🎫 #SD-2715 🟢 Remove references/links to a DCSA-maintained errorCodes page from the affected API specifications. Rewrite the errorCode description to be implementer-specific (codes maintained by the API implementor; consult the implementer for meaning).
🟢	🎫 #SD-2717 🟢 Remove references/links to a DCSA-maintained errorCode page from the CS API specification. Rewrite the errorCode description to be implementer-specific (codes maintained by the API implementor; consult the implementer for meaning). Add a note stating that DCSA previously intended to standardize errorCodes but it did not gain traction.
Codebase Duplication Compliance
⚪	Codebase context is not defined Follow the guide to enable codebase context checks.
Custom Compliance
🟢	Generic: Comprehensive Audit Trails Objective: To create a detailed and reliable record of critical system actions for security analysis and compliance. Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Meaningful Naming and Self-Documenting Code Objective: Ensure all identifiers clearly express their purpose and intent, making code self-documenting Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Robust Error Handling and Edge Case Management Objective: Ensure comprehensive error handling that provides meaningful context and graceful degradation Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Secure Error Handling Objective: To prevent the leakage of sensitive system information through error messages while providing sufficient detail for internal debugging. Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Secure Logging Practices Objective: To ensure logs are useful for debugging and auditing without exposing sensitive information like PII, PHI, or cardholder data. Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Security-First Input Validation and Data Handling Objective: Ensure all data inputs are validated, sanitized, and handled securely to prevent vulnerabilities Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
Update

Compliance status legend

🟢 - Fully Compliant
🟡 - Partial Compliant
🔴 - Not Compliant
⚪ - Requires Further Human Verification
🏷️ - Compliance label

[qodo-code-review]

PR Code Suggestions ✨

Explore these optional code suggestions:

Category	Suggestion	Impact
High-level	Re-evaluate keeping the errorCode range constraint The errorCode field is now implementer-specific, but the API specifications retain a fixed numeric range (7000-9999). This is contradictory; either remove the range constraint or clarify in the description that implementer codes must adhere to it. Examples: bkg/v2/BKG_v2.0.4.yaml [2699-2708] errorCode: type: integer format: int32 description: | The detailed error code returned. The codes returned are maintained by the implementor of the API. For further explanation as to the meaning of an errorCode please consult the implementer. **Note:** Previously it was the intention of DCSA to standardize this but it never gained traction. minimum: 7000 maximum: 9999 example: 7003 cs/v1/CS_v1.0.2.yaml [1818-1827] errorCode: type: integer format: int32 description: | The detailed error code returned. The codes returned are maintained by the implementor of the API. For further explanation as to the meaning of an errorCode please consult the implementer. **Note:** Previously it was the intention of DCSA to standardize this but it never gained traction. example: 7003 minimum: 7000 maximum: 9999 Solution Walkthrough: Before: # In bkg/v2/BKG_v2.0.4.yaml errorCode: type: integer format: int32 description: | The detailed error code returned. The codes returned are maintained by the implementor of the API. For further explanation as to the meaning of an errorCode please consult the implementer. **Note:** Previously it was the intention of DCSA to standardize this but it never gained traction. minimum: 7000 maximum: 9999 example: 7003 After: # In bkg/v2/BKG_v2.0.4.yaml # Option 1: Remove constraints errorCode: type: integer format: int32 description: | The detailed error code returned. The codes returned are maintained by the implementor of the API. For further explanation as to the meaning of an errorCode please consult the implementer. ... example: 7003 # Option 2: Clarify constraints in description errorCode: type: integer format: int32 description: | The detailed error code returned, which must be between 7000 and 9999. The codes returned are maintained by the implementor of the API. ... minimum: 7000 maximum: 9999 Suggestion importance[1-10]: 8 __ Why: The suggestion correctly identifies a logical contradiction where errorCode is made implementer-specific, yet the numeric range constraints (minimum and maximum) are retained, creating significant ambiguity in the API specifications.	Medium
General	Centralize errorCode schema To reduce duplication, extract the errorCode definition into a reusable component schema and reference it using $ref. bkg/v2/BKG_v2.0.4.yaml [2699-2708] errorCode: - type: integer - format: int32 - description: | - The detailed error code returned. The codes returned are maintained by the implementor of the API. For further explanation as to the meaning of an errorCode please consult the implementer. - minimum: 7000 - maximum: 9999 - example: 7003 + $ref: '#/components/schemas/ErrorCode' [To ensure code accuracy, apply this suggestion manually] Suggestion importance[1-10]: 7 __ Why: This is a valuable suggestion that follows OpenAPI best practices (DRY principle) to improve maintainability by centralizing the duplicated errorCode schema, which is modified across many files in this PR.	Medium
	Add error code docs link Add an externalDocs field to the errorCode schema to provide a direct link to the implementer's error code documentation. bkg/v2/BKG_v2.0.4.yaml [2699-2708] errorCode: type: integer format: int32 + externalDocs: + description: Implementer error codes documentation + url: https://<your-implementer-docs-url> example: 7003 [To ensure code accuracy, apply this suggestion manually] Suggestion importance[1-10]: 5 __ Why: The suggestion is relevant to the PR's goal of clarifying that error codes are implementer-specific by proposing the use of externalDocs to link to their documentation, which improves the API's usability.	Low
	Use consistent spelling for "implementer" Standardize the spelling of "implementor" to "implementer" for consistency across all modified files. bkg/v2/BKG_v2.0.4.yaml [2702-2705] description: | - The detailed error code returned. The codes returned are maintained by the implementor of the API. For further explanation as to the meaning of an errorCode please consult the implementer. + The detailed error code returned. The codes returned are maintained by the implementer of the API. For further explanation as to the meaning of an errorCode please consult the implementer. **Note:** Previously it was the intention of DCSA to standardize this but it never gained traction. Apply / Chat Suggestion importance[1-10]: 3 __ Why: The suggestion correctly identifies an inconsistent spelling ("implementor" vs. "implementer") in the new description text and proposes a fix, which improves consistency and professionalism.	Low
Update