Adding Required Fields for Accelerator extensions v1.0.4 - #930
Adding Required Fields for Accelerator extensions v1.0.4#930De-Silva-Madhushankha wants to merge 6 commits into
Conversation
📝 WalkthroughChanges SummaryThis PR updates the OpenAPI schema definitions to add validation constraints for consent and authorization data structures. Schema UpdatesDetailedConsentResourceData - Added required fields:
Authorization - Added required fields:
These changes enforce stricter validation on API responses, ensuring that consent and authorization objects include these mandatory fields. Development Status
Related Issue
WalkthroughThe OpenAPI 3.0.1 specification file Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 5
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In
`@financial-services-accelerator/accelerators/fs-is/repository/resources/apis/accelerator-extensions-v1.0.4.yaml`:
- Around line 2413-2443: Add a required constraint to both
AppCreateProcessRequestBody and AppUpdateProcessRequestBody so that "requestId"
and "data" are mandatory (match the pattern used by other request-body schemas);
update the schema objects AppCreateProcessRequestBody and
AppUpdateProcessRequestBody to include a required: ["requestId","data"] entry so
the endpoints cannot accept an empty object for those wrappers.
- Around line 1774-1782: The OpenAPI schema object
SuccessResponseConsentRevocationData defines requireTokenRevocation as type
string but the Java DTOs ExternalAPIConsentRevokeResponseDTO and
ExternalAPIAdminConsentRevokeResponseDTO (and test data) use boolean; update the
OpenAPI spec by changing the requireTokenRevocation property's type from
"string" to "boolean" (keep the description intact) so generated clients will
match the Java DTOs.
- Around line 2512-2532: The schema is inconsistent:
FailedResponseApplicationProcess lists "data" as required but has no data
property, and currently exposes errorMessage at the top level as a $ref to
FailedResponseApplicationProcessData while examples expect data.errorMessage as
a simple string. Fix by adding a "data" property to
FailedResponseApplicationProcess that $ref's
FailedResponseApplicationProcessData (and remove the top-level errorMessage
property), and ensure FailedResponseApplicationProcessData defines errorMessage
as type: string so the payload shape becomes { status: "ERROR", data: {
errorMessage: "..." } } matching the examples.
- Around line 1843-1868: The Response200ForPersistAuthorizedConsent oneOf
branches are not mutually exclusive because
SuccessResponseWithDetailedConsentData and
SuccessResponseWithDetailedConsentDataAndAmendments omit required fields
(notably consentResource) and DetailedConsentResourceDataWithAmendments has no
required fields; either make the branches exclusive by adding a required
consentResource to both wrapper schemas (SuccessResponseWithDetailedConsentData
and SuccessResponseWithDetailedConsentDataAndAmendments) and tighten
DetailedConsentResourceDataWithAmendments (e.g., require amendments plus any
other fields that distinguish it from DetailedConsentResourceData), or change
the oneOf to anyOf if overlapping shapes are intentional; update the schemas
named SuccessResponsePersistAuthorizedConsent,
SuccessResponseWithDetailedConsentData,
SuccessResponseWithDetailedConsentDataAndAmendments,
DetailedConsentResourceDataWithAmendments, and DetailedConsentResourceData
accordingly.
- Around line 755-760: The operation-level requestBody for
PopulateConsentAuthorizeScreen (which references the
PopulateConsentAuthorizeScreenRequestBody schema) is missing required: true so
validators may accept an empty body; update that requestBody to include
required: true and apply the same change to the six other operations using the
same pattern (/map-accelerator-error-response, /pre-process-client-creation,
/pre-process-client-update, /pre-process-client-retrieval,
/pre-process-application-creation, /pre-process-application-update) so each
requestBody that references a schema that enforces required properties
explicitly sets required: true at the operation level.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: e9c4e95b-9046-4ba3-a889-e10140bc7d6b
📒 Files selected for processing (1)
financial-services-accelerator/accelerators/fs-is/repository/resources/apis/accelerator-extensions-v1.0.4.yaml
| requestBody: | ||
| content: | ||
| application/json: | ||
| schema: | ||
| $ref: '#/components/schemas/PopulateConsentAuthorizeScreenRequestBody' | ||
| responses: |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# First, check file existence and size
wc -l "financial-services-accelerator/accelerators/fs-is/repository/resources/apis/accelerator-extensions-v1.0.4.yaml"Repository: wso2/financial-services-accelerator
Length of output: 194
🏁 Script executed:
# Read the section around lines 755-760
sed -n '750,765p' "financial-services-accelerator/accelerators/fs-is/repository/resources/apis/accelerator-extensions-v1.0.4.yaml"Repository: wso2/financial-services-accelerator
Length of output: 571
🏁 Script executed:
# Read the schema definition around lines 1649-1659
sed -n '1645,1670p' "financial-services-accelerator/accelerators/fs-is/repository/resources/apis/accelerator-extensions-v1.0.4.yaml"Repository: wso2/financial-services-accelerator
Length of output: 796
🏁 Script executed:
# Check the full /populate-consent-authorize-screen operation context
sed -n '745,770p' "financial-services-accelerator/accelerators/fs-is/repository/resources/apis/accelerator-extensions-v1.0.4.yaml"Repository: wso2/financial-services-accelerator
Length of output: 960
🏁 Script executed:
# Look for other POST operations with requestBody to check consistency patterns
rg -n "requestBody:" "financial-services-accelerator/accelerators/fs-is/repository/resources/apis/accelerator-extensions-v1.0.4.yaml" -A 3 | head -60Repository: wso2/financial-services-accelerator
Length of output: 1306
🏁 Script executed:
# Check if any requestBody definitions have the required: true flag
rg -n "requestBody:" "financial-services-accelerator/accelerators/fs-is/repository/resources/apis/accelerator-extensions-v1.0.4.yaml" -A 2 | grep -E "(requestBody:|required:)" | head -40Repository: wso2/financial-services-accelerator
Length of output: 632
🏁 Script executed:
# Get a broader context around one operation to see the full requestBody structure
sed -n '35,50p' "financial-services-accelerator/accelerators/fs-is/repository/resources/apis/accelerator-extensions-v1.0.4.yaml"Repository: wso2/financial-services-accelerator
Length of output: 601
🏁 Script executed:
# Check another operation to see if they follow the same pattern
sed -n '86,100p' "financial-services-accelerator/accelerators/fs-is/repository/resources/apis/accelerator-extensions-v1.0.4.yaml"Repository: wso2/financial-services-accelerator
Length of output: 630
🏁 Script executed:
# For each requestBody, check if it has required: true in the next 5 lines
rg -n "requestBody:" "financial-services-accelerator/accelerators/fs-is/repository/resources/apis/accelerator-extensions-v1.0.4.yaml" -A 5 | grep -B 1 "required: true" | head -40Repository: wso2/financial-services-accelerator
Length of output: 1572
🏁 Script executed:
# Count how many requestBody entries have required: true
rg -c "required: true" "financial-services-accelerator/accelerators/fs-is/repository/resources/apis/accelerator-extensions-v1.0.4.yaml"Repository: wso2/financial-services-accelerator
Length of output: 81
🏁 Script executed:
# Get exact line numbers for all "required: true" entries
rg -n "required: true" "financial-services-accelerator/accelerators/fs-is/repository/resources/apis/accelerator-extensions-v1.0.4.yaml"Repository: wso2/financial-services-accelerator
Length of output: 702
🏁 Script executed:
# Check lines 755-765 to see if required: true is present
sed -n '755,765p' "financial-services-accelerator/accelerators/fs-is/repository/resources/apis/accelerator-extensions-v1.0.4.yaml"Repository: wso2/financial-services-accelerator
Length of output: 376
🏁 Script executed:
# Check the operation at line 794 (next requestBody) to see the pattern
sed -n '794,810p' "financial-services-accelerator/accelerators/fs-is/repository/resources/apis/accelerator-extensions-v1.0.4.yaml"Repository: wso2/financial-services-accelerator
Length of output: 593
🏁 Script executed:
# Check which operations are missing the required: true flag
# by comparing requestBody line numbers with required: true line numbers
python3 << 'EOF'
requestBody_lines = [37, 88, 158, 229, 296, 364, 433, 474, 514, 555, 595, 635, 675, 715, 755, 794, 836, 892, 933, 986, 1051, 1107, 1162, 1217]
required_lines = [49, 103, 175, 242, 311, 381, 438, 479, 519, 560, 600, 640, 680, 720, 799, 841, 897, 938, 991, 1056, 1112, 1167, 1222]
# For each requestBody, find its corresponding required flag (should be within ~10 lines after)
missing_required = []
for rb_line in requestBody_lines:
# Check if there's a required: true within the next 10 lines
found = False
for req_line in required_lines:
if rb_line < req_line <= rb_line + 10:
found = True
break
if not found:
missing_required.append(rb_line)
print("RequestBody entries missing 'required: true' flag:")
for line in missing_required:
print(f" Line {line}")
EOFRepository: wso2/financial-services-accelerator
Length of output: 204
🏁 Script executed:
# Get the operation names for the requestBody entries missing required: true
python3 << 'EOF'
missing_lines = [37, 88, 158, 229, 296, 364, 755]
for line_num in missing_lines:
# Read from file and find the operation path (lines before requestBody)
with open("financial-services-accelerator/accelerators/fs-is/repository/resources/apis/accelerator-extensions-v1.0.4.yaml") as f:
lines = f.readlines()
# Search backwards from requestBody line to find the path
for i in range(line_num - 1, max(0, line_num - 20), -1):
if lines[i].strip().startswith('/'):
path = lines[i].strip()
print(f"Line {line_num}: {path}")
break
EOFRepository: wso2/financial-services-accelerator
Length of output: 372
🏁 Script executed:
# Verify the OpenAPI 3.0.1 spec behavior on optional requestBody
web_search
OpenAPI 3.0.1 requestBody required field default behavior schema validationRepository: wso2/financial-services-accelerator
Length of output: 175
🌐 Web query:
OpenAPI 3.0.1 requestBody required field default behavior when not specified
💡 Result:
In OpenAPI 3.0.1, the requestBody object’s required flag defaults to false when omitted—so the request body is optional unless you explicitly set required: true. [1]
If the entire requestBody is not present on an operation, then the OpenAPI document simply doesn’t define a request body for that operation (i.e., there is no request-body contract to validate/generate against). Also note requestBody is only meaningful for HTTP methods where the HTTP spec defines request-body semantics; otherwise, it is ignored by consumers. [2]
Sources:
[1] OpenAPI Spec 3.0.1 — Request Body Object (required defaults to false) (spec.openapis.org)
[2] OpenAPI Spec 3.0.1 — Operation Object (requestBody support/ignored cases) (spec.openapis.org)
Citations:
Add required: true to the authorize-screen request body—and other operations using the same pattern.
Line 755 defines PopulateConsentAuthorizeScreenRequestBody (which requires requestId and data), but the operation-level requestBody does not set required: true. In OpenAPI 3.0.1, this defaults to false, allowing validators to accept an empty body and defer schema violations to runtime.
This same gap affects 6 other operations in this file: /map-accelerator-error-response, /pre-process-client-creation, /pre-process-client-update, /pre-process-client-retrieval, /pre-process-application-creation, and /pre-process-application-update.
Suggested fix for line 755
/populate-consent-authorize-screen:
post:
tags:
- Consent
summary: handle validations before consent authorization and consent data to load in consent authorization UI
requestBody:
+ required: true
content:
application/json:
schema:
$ref: '#/components/schemas/PopulateConsentAuthorizeScreenRequestBody'📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| requestBody: | |
| content: | |
| application/json: | |
| schema: | |
| $ref: '#/components/schemas/PopulateConsentAuthorizeScreenRequestBody' | |
| responses: | |
| requestBody: | |
| required: true | |
| content: | |
| application/json: | |
| schema: | |
| $ref: '#/components/schemas/PopulateConsentAuthorizeScreenRequestBody' | |
| responses: |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In
`@financial-services-accelerator/accelerators/fs-is/repository/resources/apis/accelerator-extensions-v1.0.4.yaml`
around lines 755 - 760, The operation-level requestBody for
PopulateConsentAuthorizeScreen (which references the
PopulateConsentAuthorizeScreenRequestBody schema) is missing required: true so
validators may accept an empty body; update that requestBody to include
required: true and apply the same change to the six other operations using the
same pattern (/map-accelerator-error-response, /pre-process-client-creation,
/pre-process-client-update, /pre-process-client-retrieval,
/pre-process-application-creation, /pre-process-application-update) so each
requestBody that references a schema that enforces required properties
explicitly sets required: true at the operation level.
| SuccessResponseConsentRevocationData: | ||
| type: object | ||
| properties: | ||
| revocationStatusName: | ||
| type: string | ||
| description: Name for the revoked status | ||
| requireTokenRevocation: | ||
| type: string | ||
| description: Require access token to be revoked |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# First, locate the file and confirm it exists
find . -name "accelerator-extensions-v1.0.4.yaml" -type fRepository: wso2/financial-services-accelerator
Length of output: 191
🏁 Script executed:
# Read the specific lines mentioned in the review
sed -n '1774,1782p' financial-services-accelerator/accelerators/fs-is/repository/resources/apis/accelerator-extensions-v1.0.4.yamlRepository: wso2/financial-services-accelerator
Length of output: 374
🏁 Script executed:
# Get broader context around these lines to understand the schema structure
sed -n '1770,1800p' financial-services-accelerator/accelerators/fs-is/repository/resources/apis/accelerator-extensions-v1.0.4.yamlRepository: wso2/financial-services-accelerator
Length of output: 1150
🏁 Script executed:
# Search for references to SuccessResponseConsentRevocationData to find usage/examples
rg "SuccessResponseConsentRevocationData" --type yaml --type json -A 5 -B 2Repository: wso2/financial-services-accelerator
Length of output: 11879
🏁 Script executed:
# Search for requireTokenRevocation field references to see how it's used
rg "requireTokenRevocation" -A 2 -B 2Repository: wso2/financial-services-accelerator
Length of output: 12164
🏁 Script executed:
# Search for example values or test data that might show the intended type
rg "revocationStatusName\|requireTokenRevocation" --type json -A 2 -B 2Repository: wso2/financial-services-accelerator
Length of output: 61
Change requireTokenRevocation from string to boolean.
The Java implementation in ExternalAPIConsentRevokeResponseDTO and ExternalAPIAdminConsentRevokeResponseDTO defines this field as boolean, and test data uses boolean values (true), but the OpenAPI schema incorrectly specifies string. This mismatch will cause generated client code to have the wrong types.
Suggested fix
SuccessResponseConsentRevocationData:
type: object
properties:
revocationStatusName:
type: string
description: Name for the revoked status
requireTokenRevocation:
- type: string
+ type: boolean
description: Require access token to be revoked📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| SuccessResponseConsentRevocationData: | |
| type: object | |
| properties: | |
| revocationStatusName: | |
| type: string | |
| description: Name for the revoked status | |
| requireTokenRevocation: | |
| type: string | |
| description: Require access token to be revoked | |
| SuccessResponseConsentRevocationData: | |
| type: object | |
| properties: | |
| revocationStatusName: | |
| type: string | |
| description: Name for the revoked status | |
| requireTokenRevocation: | |
| type: boolean | |
| description: Require access token to be revoked |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In
`@financial-services-accelerator/accelerators/fs-is/repository/resources/apis/accelerator-extensions-v1.0.4.yaml`
around lines 1774 - 1782, The OpenAPI schema object
SuccessResponseConsentRevocationData defines requireTokenRevocation as type
string but the Java DTOs ExternalAPIConsentRevokeResponseDTO and
ExternalAPIAdminConsentRevokeResponseDTO (and test data) use boolean; update the
OpenAPI spec by changing the requireTokenRevocation property's type from
"string" to "boolean" (keep the description intact) so generated clients will
match the Java DTOs.
| Response200ForPersistAuthorizedConsent: | ||
| oneOf: | ||
| - $ref: '#/components/schemas/SuccessResponsePersistAuthorizedConsent' | ||
| - $ref: '#/components/schemas/FailedResponseInConsentAuthorize' | ||
| SuccessResponsePersistAuthorizedConsent: | ||
| type: object | ||
| required: | ||
| - responseId | ||
| - status | ||
| - data | ||
| properties: | ||
| responseId: | ||
| type: string | ||
| status: | ||
| type: string | ||
| enum: | ||
| - SUCCESS | ||
| data: | ||
| oneOf: | ||
| - $ref: '#/components/schemas/SuccessResponseWithDetailedConsentData' | ||
| - $ref: '#/components/schemas/SuccessResponseWithDetailedConsentDataAndAmendments' | ||
| SuccessResponseWithDetailedConsentDataAndAmendments: | ||
| type: object | ||
| properties: | ||
| consentResource: | ||
| $ref: '#/components/schemas/DetailedConsentResourceDataWithAmendments' |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
find . -name "accelerator-extensions-v1.0.4.yaml" -type fRepository: wso2/financial-services-accelerator
Length of output: 191
🏁 Script executed:
sed -n '1843,1900p' ./financial-services-accelerator/accelerators/fs-is/repository/resources/apis/accelerator-extensions-v1.0.4.yamlRepository: wso2/financial-services-accelerator
Length of output: 1706
🏁 Script executed:
sed -n '1900,1950p' ./financial-services-accelerator/accelerators/fs-is/repository/resources/apis/accelerator-extensions-v1.0.4.yamlRepository: wso2/financial-services-accelerator
Length of output: 1246
🏁 Script executed:
rg -n "SuccessResponseWithDetailedConsentData:" ./financial-services-accelerator/accelerators/fs-is/repository/resources/apis/accelerator-extensions-v1.0.4.yamlRepository: wso2/financial-services-accelerator
Length of output: 127
🏁 Script executed:
sed -n '1798,1843p' ./financial-services-accelerator/accelerators/fs-is/repository/resources/apis/accelerator-extensions-v1.0.4.yamlRepository: wso2/financial-services-accelerator
Length of output: 1479
Make the persisted-consent oneOf branches mutually exclusive.
Both wrapper schemas (SuccessResponseWithDetailedConsentData and SuccessResponseWithDetailedConsentDataAndAmendments) lack consentResource in their required fields. This allows the same payload to match both branches—for example, an empty object or an object with only optional fields would satisfy both schemas. Additionally, DetailedConsentResourceDataWithAmendments has no required fields despite the amendments property being present, whereas DetailedConsentResourceData requires seven fields. This breaks the oneOf contract and leaves the amended response path without the tightened validation.
Suggested fix
SuccessResponseWithDetailedConsentData:
type: object
+ required:
+ - consentResource
properties:
consentResource:
$ref: '#/components/schemas/DetailedConsentResourceData'
@@
SuccessResponseWithDetailedConsentDataAndAmendments:
type: object
+ required:
+ - consentResource
properties:
consentResource:
$ref: '#/components/schemas/DetailedConsentResourceDataWithAmendments'
DetailedConsentResourceDataWithAmendments:
type: object
+ required:
+ - type
+ - status
+ - receipt
+ - recurringIndicator
+ - frequency
+ - validityTime
+ - authorizations
+ - amendments
properties:
type:
type: stringIf both shapes are intentionally allowed to overlap, anyOf would be a better fit than oneOf.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In
`@financial-services-accelerator/accelerators/fs-is/repository/resources/apis/accelerator-extensions-v1.0.4.yaml`
around lines 1843 - 1868, The Response200ForPersistAuthorizedConsent oneOf
branches are not mutually exclusive because
SuccessResponseWithDetailedConsentData and
SuccessResponseWithDetailedConsentDataAndAmendments omit required fields
(notably consentResource) and DetailedConsentResourceDataWithAmendments has no
required fields; either make the branches exclusive by adding a required
consentResource to both wrapper schemas (SuccessResponseWithDetailedConsentData
and SuccessResponseWithDetailedConsentDataAndAmendments) and tighten
DetailedConsentResourceDataWithAmendments (e.g., require amendments plus any
other fields that distinguish it from DetailedConsentResourceData), or change
the oneOf to anyOf if overlapping shapes are intentional; update the schemas
named SuccessResponsePersistAuthorizedConsent,
SuccessResponseWithDetailedConsentData,
SuccessResponseWithDetailedConsentDataAndAmendments,
DetailedConsentResourceDataWithAmendments, and DetailedConsentResourceData
accordingly.
| AppCreateProcessRequestBody: | ||
| type: object | ||
| properties: | ||
| requestId: | ||
| type: string | ||
| description: A unique correlation identifier | ||
| example: Ec1wMjmiG8 | ||
| data: | ||
| $ref: '#/components/schemas/AppCreateProcessData' | ||
| AppCreateProcessData: | ||
| type: object | ||
| required: | ||
| - appData | ||
| - additionalProperties | ||
| properties: | ||
| appData: | ||
| type: object | ||
| description: OAuth Application Data. Mandatory for pre-process-application-creation. | ||
| additionalProperties: | ||
| type: object | ||
| description: Additional properties retrieved from devportal UI. Mandatory for pre-process-application-creation. | ||
| description: Defines the context data related to the application registration. | ||
| AppUpdateProcessRequestBody: | ||
| type: object | ||
| properties: | ||
| requestId: | ||
| type: string | ||
| description: A unique correlation identifier | ||
| example: Ec1wMjmiG8 | ||
| data: | ||
| $ref: '#/components/schemas/AppUpdateProcessData' |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# First, check the file exists and get basic info
find . -name "accelerator-extensions-v1.0.4.yaml" -type fRepository: wso2/financial-services-accelerator
Length of output: 191
🏁 Script executed:
# Read the specific lines mentioned in the review
sed -n '2413,2443p' financial-services-accelerator/accelerators/fs-is/repository/resources/apis/accelerator-extensions-v1.0.4.yamlRepository: wso2/financial-services-accelerator
Length of output: 1143
🏁 Script executed:
# Check the cited endpoint definitions at lines 296-311 and 364-381
sed -n '296,311p' financial-services-accelerator/accelerators/fs-is/repository/resources/apis/accelerator-extensions-v1.0.4.yamlRepository: wso2/financial-services-accelerator
Length of output: 596
🏁 Script executed:
# Check the second endpoint range
sed -n '364,381p' financial-services-accelerator/accelerators/fs-is/repository/resources/apis/accelerator-extensions-v1.0.4.yamlRepository: wso2/financial-services-accelerator
Length of output: 662
🏁 Script executed:
# Search for all RequestBody schemas in the file to see the pattern
rg "RequestBody:" financial-services-accelerator/accelerators/fs-is/repository/resources/apis/accelerator-extensions-v1.0.4.yaml -A 10 | head -100Repository: wso2/financial-services-accelerator
Length of output: 2361
Require requestId and data on the application-process wrappers.
AppCreateProcessRequestBody and AppUpdateProcessRequestBody lack required declarations unlike every other request-body schema in this file. Both allow an empty object, yet the endpoints, examples, and consistent pattern across 9+ other schemas all expect both requestId and data to be mandatory. Add the required constraint to enforce the contract.
Suggested fix
AppCreateProcessRequestBody:
type: object
+ required:
+ - requestId
+ - data
properties:
requestId:
type: string
@@
AppUpdateProcessRequestBody:
type: object
+ required:
+ - requestId
+ - data
properties:
requestId:
type: string📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| AppCreateProcessRequestBody: | |
| type: object | |
| properties: | |
| requestId: | |
| type: string | |
| description: A unique correlation identifier | |
| example: Ec1wMjmiG8 | |
| data: | |
| $ref: '#/components/schemas/AppCreateProcessData' | |
| AppCreateProcessData: | |
| type: object | |
| required: | |
| - appData | |
| - additionalProperties | |
| properties: | |
| appData: | |
| type: object | |
| description: OAuth Application Data. Mandatory for pre-process-application-creation. | |
| additionalProperties: | |
| type: object | |
| description: Additional properties retrieved from devportal UI. Mandatory for pre-process-application-creation. | |
| description: Defines the context data related to the application registration. | |
| AppUpdateProcessRequestBody: | |
| type: object | |
| properties: | |
| requestId: | |
| type: string | |
| description: A unique correlation identifier | |
| example: Ec1wMjmiG8 | |
| data: | |
| $ref: '#/components/schemas/AppUpdateProcessData' | |
| AppCreateProcessRequestBody: | |
| type: object | |
| required: | |
| - requestId | |
| - data | |
| properties: | |
| requestId: | |
| type: string | |
| description: A unique correlation identifier | |
| example: Ec1wMjmiG8 | |
| data: | |
| $ref: '#/components/schemas/AppCreateProcessData' | |
| AppCreateProcessData: | |
| type: object | |
| required: | |
| - appData | |
| - additionalProperties | |
| properties: | |
| appData: | |
| type: object | |
| description: OAuth Application Data. Mandatory for pre-process-application-creation. | |
| additionalProperties: | |
| type: object | |
| description: Additional properties retrieved from devportal UI. Mandatory for pre-process-application-creation. | |
| description: Defines the context data related to the application registration. | |
| AppUpdateProcessRequestBody: | |
| type: object | |
| required: | |
| - requestId | |
| - data | |
| properties: | |
| requestId: | |
| type: string | |
| description: A unique correlation identifier | |
| example: Ec1wMjmiG8 | |
| data: | |
| $ref: '#/components/schemas/AppUpdateProcessData' |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In
`@financial-services-accelerator/accelerators/fs-is/repository/resources/apis/accelerator-extensions-v1.0.4.yaml`
around lines 2413 - 2443, Add a required constraint to both
AppCreateProcessRequestBody and AppUpdateProcessRequestBody so that "requestId"
and "data" are mandatory (match the pattern used by other request-body schemas);
update the schema objects AppCreateProcessRequestBody and
AppUpdateProcessRequestBody to include a required: ["requestId","data"] entry so
the endpoints cannot accept an empty object for those wrappers.
| FailedResponseApplicationProcess: | ||
| required: | ||
| - data | ||
| - status | ||
| type: object | ||
| properties: | ||
| status: | ||
| type: string | ||
| description: "Indicates the outcome of the request. For a failed operation, this should be set to ERROR." | ||
| enum: | ||
| - ERROR | ||
| errorMessage: | ||
| $ref: '#/components/schemas/FailedResponseApplicationProcessData' | ||
| FailedResponseApplicationProcessData: | ||
| required: | ||
| - errorMessage | ||
| type: object | ||
| properties: | ||
| errorMessage: | ||
| type: string | ||
| description: Error message to be returned |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
find . -type f -name "accelerator-extensions-v1.0.4.yaml" 2>/dev/nullRepository: wso2/financial-services-accelerator
Length of output: 191
🏁 Script executed:
wc -l ./financial-services-accelerator/accelerators/fs-is/repository/resources/apis/accelerator-extensions-v1.0.4.yamlRepository: wso2/financial-services-accelerator
Length of output: 196
🏁 Script executed:
sed -n '2512,2532p' ./financial-services-accelerator/accelerators/fs-is/repository/resources/apis/accelerator-extensions-v1.0.4.yamlRepository: wso2/financial-services-accelerator
Length of output: 705
🏁 Script executed:
sed -n '332,334p' ./financial-services-accelerator/accelerators/fs-is/repository/resources/apis/accelerator-extensions-v1.0.4.yamlRepository: wso2/financial-services-accelerator
Length of output: 215
🏁 Script executed:
sed -n '400,403p' ./financial-services-accelerator/accelerators/fs-is/repository/resources/apis/accelerator-extensions-v1.0.4.yamlRepository: wso2/financial-services-accelerator
Length of output: 240
FailedResponseApplicationProcess cannot validate as written.
The schema requires a data property that does not exist in the defined properties. Additionally, errorMessage is modeled as a reference to FailedResponseApplicationProcessData (an object), but the examples at lines 332-334 and 400-403 show it as a simple string field. This mismatch will cause schema validators and generated clients to reject payloads that match the documented examples.
Suggested fix
FailedResponseApplicationProcess:
required:
- - data
- status
+ - errorMessage
type: object
properties:
status:
type: string
description: "Indicates the outcome of the request. For a failed operation, this should be set to ERROR."
enum:
- ERROR
errorMessage:
- $ref: '#/components/schemas/FailedResponseApplicationProcessData'
- FailedResponseApplicationProcessData:
- required:
- - errorMessage
- type: object
- properties:
- errorMessage:
- type: string
- description: Error message to be returned
+ type: string
+ description: Error message to be returned📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| FailedResponseApplicationProcess: | |
| required: | |
| - data | |
| - status | |
| type: object | |
| properties: | |
| status: | |
| type: string | |
| description: "Indicates the outcome of the request. For a failed operation, this should be set to ERROR." | |
| enum: | |
| - ERROR | |
| errorMessage: | |
| $ref: '#/components/schemas/FailedResponseApplicationProcessData' | |
| FailedResponseApplicationProcessData: | |
| required: | |
| - errorMessage | |
| type: object | |
| properties: | |
| errorMessage: | |
| type: string | |
| description: Error message to be returned | |
| FailedResponseApplicationProcess: | |
| required: | |
| - status | |
| - errorMessage | |
| type: object | |
| properties: | |
| status: | |
| type: string | |
| description: "Indicates the outcome of the request. For a failed operation, this should be set to ERROR." | |
| enum: | |
| - ERROR | |
| errorMessage: | |
| type: string | |
| description: Error message to be returned |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In
`@financial-services-accelerator/accelerators/fs-is/repository/resources/apis/accelerator-extensions-v1.0.4.yaml`
around lines 2512 - 2532, The schema is inconsistent:
FailedResponseApplicationProcess lists "data" as required but has no data
property, and currently exposes errorMessage at the top level as a $ref to
FailedResponseApplicationProcessData while examples expect data.errorMessage as
a simple string. Fix by adding a "data" property to
FailedResponseApplicationProcess that $ref's
FailedResponseApplicationProcessData (and remove the top-level errorMessage
property), and ensure FailedResponseApplicationProcessData defines errorMessage
as type: string so the payload shape becomes { status: "ERROR", data: {
errorMessage: "..." } } matching the examples.
There was a problem hiding this comment.
🧹 Nitpick comments (1)
financial-services-accelerator/accelerators/fs-is/repository/resources/apis/accelerator-extensions-v1.0.4.yaml (1)
1987-2002: LGTM —Authorizationrequired fields align with backend DTO.Marking
typeandstatusas required is consistent with the innerAuthorizationclass inExternalAPIConsentResourceResponseDTO.userIdandresourcesremain optional, which matches the DTO (no enforcement on those) and the various flows that may omit them.Optional consideration (non-blocking):
AmendedAuthorization(lines 2003–2019) andStoredAuthorization(lines 2020–2034) describe the same logical authorization shape but have norequireddeclarations. If they represent the same domain entity at different lifecycle stages, applying the same required fields would improve schema consistency. Defer if the intent is to keep stored/historical shapes lenient.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@financial-services-accelerator/accelerators/fs-is/repository/resources/apis/accelerator-extensions-v1.0.4.yaml` around lines 1987 - 2002, The YAML defines required fields (type, status) for Authorization matching ExternalAPIConsentResourceResponseDTO, but AmendedAuthorization and StoredAuthorization omit required declarations; to improve schema consistency, add the same required array (type, status) to the AmendedAuthorization and StoredAuthorization schema objects so they mirror Authorization and the DTO (leave userId and resources optional if intended), ensuring the symbols AmendedAuthorization and StoredAuthorization are updated accordingly to match Authorization/ExternalAPIConsentResourceResponseDTO.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In
`@financial-services-accelerator/accelerators/fs-is/repository/resources/apis/accelerator-extensions-v1.0.4.yaml`:
- Around line 1987-2002: The YAML defines required fields (type, status) for
Authorization matching ExternalAPIConsentResourceResponseDTO, but
AmendedAuthorization and StoredAuthorization omit required declarations; to
improve schema consistency, add the same required array (type, status) to the
AmendedAuthorization and StoredAuthorization schema objects so they mirror
Authorization and the DTO (leave userId and resources optional if intended),
ensuring the symbols AmendedAuthorization and StoredAuthorization are updated
accordingly to match Authorization/ExternalAPIConsentResourceResponseDTO.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 790600ea-26a2-4f35-aee7-b1ced1ba1b2a
📒 Files selected for processing (1)
financial-services-accelerator/accelerators/fs-is/repository/resources/apis/accelerator-extensions-v1.0.4.yaml
1 participant
Pull Request Title
Issue link: #926
Doc Issue: Optional, link issue from documentation repository
Applicable Labels: Spec, product, version, type (specify requested labels)
Development Checklist
Testing Checklist