[INJICERT-990] Add Presentation during Issuance design doc, apis doc and postman collections #549
Conversation
Signed-off-by: Piyush7034 <piyushshukla2100@gmail.com>
WalkthroughThis pull request introduces OAuth 2.0 JWKS URI support and Presentation During Issuance workflows for the Inji Certify service, adding API documentation, configuration properties, service wiring, Postman test collections, and comprehensive tests to enable VP-gated credential issuance flows. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Possibly related PRs
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches
📜 Recent review detailsConfiguration used: Organization UI Review profile: CHILL Plan: Pro 📒 Files selected for processing (2)
🚧 Files skipped from review as they are similar to previous changes (1)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
🔇 Additional comments (3)
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: 6
🤖 Fix all issues with AI agents
In @docs/inji-certify-openapi.yaml:
- Around line 2821-2843: The AuthorizationSuccess schema lists a required field
named "authorization_code" that does not exist; rename the required entry to
"code" (or remove the required array and document that "code" is only present
when status == "ok") so the schema matches the defined property; update the
AuthorizationSuccess schema's required array to include "code" (or remove it and
add conditional documentation referencing the status field) to resolve the
mismatch between the required declaration and the actual property names.
In @docs/postman-collections/Inji Certify - Presentation During Issuance
VCI.postman_collection.json:
- Around line 524-528: There are duplicate Postman collection variables named
"url" and "client_secret" with conflicting/empty values; remove the redundant
entries and consolidate each variable to a single definition with the correct
value (ensure only one "url" variable and one "client_secret" variable exist),
update any consumer references if needed to point to the consolidated variable,
and verify the final non-empty values are the intended ones so the collection
behaves predictably.
- Around line 427-442: The credential request uses a hardcoded URL; replace the
hardcoded "raw" and corresponding "host"/"path" entries with a Postman
environment variable (e.g., use "{{baseUrl}}/v1/certify/issuance/credential" in
the "raw" field and set "host" to ["{{baseUrl}}"] or remove host and use raw
only) so the credential endpoint becomes configurable across environments;
mirror the same variable used for the token endpoint to maintain consistency
with the collection.
- Around line 345-347: The collection item name contains a typo: change the
"name" value "5. Creedential download" to "5. Credential download" in the
Postman collection JSON (the object with "name": "5. Creedential download" and
"item": [...]) so the collection displays the correct spelling; update only the
"name" string for that object.
- Around line 324-339: The hardcoded token URL in the request's "url" object
(the "raw" field currently set to
"https://injicertify-mdl.dev-int-inji.mosip.net/v1/certify/oauth/token") breaks
portability; replace that raw value with a collection/environment variable such
as "{{token_endpoint}}" or build it from "{{certifyurl}}/oauth/token" and ensure
the host/path entries or the "url" object are updated consistently so the
request uses the variable instead of the literal host.
In @docs/Presentation-During-Issuance.md:
- Around line 109-111: Replace the incorrect identifier "response_node" with
"response_mode" in the POST Content-Type block and any related bullet points
(the lines referencing `iar-post` and `iar-post.jwt`) so they match the correct
`response_mode` usage elsewhere in the document (e.g., where `response_mode` is
used on line 53); search for "response_node" and update each occurrence to
"response_mode" to ensure consistency.
🧹 Nitpick comments (3)
docs/inji-certify-openapi.yaml (2)
2780-2820: Consider addingrequiredproperties toIarRequestschema.For OAuth/OpenID flows, certain fields like
response_type,client_id, andcode_challengeare typically mandatory. Definingrequiredproperties helps with request validation and API documentation clarity.♻️ Suggested addition
IarRequest: type: object + required: + - response_type + - client_id properties: response_type:
2844-2858: Consider addingrequiredproperties toOAuthTokenRequestschema.The
grant_typefield is mandatory per OAuth 2.0 spec (RFC 6749). Marking it as required improves API validation.♻️ Suggested addition
OAuthTokenRequest: type: object + required: + - grant_type properties: grant_type:docs/postman-collections/Inji Certify - Presentation During Issuance VCI.postman_collection.json (1)
9-11: Remove "Copy" suffix from folder names."Discovery Endpoints Copy" and "OAuth Token Exchange Copy" appear to be leftover text from duplicating folders. Consider cleaning up the names.
Also applies to: 246-248
📜 Review details
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (4)
docs/Presentation-During-Issuance.mddocs/inji-certify-openapi.yamldocs/postman-collections/Inji Certify - Presentation During Issuance VCI.postman_collection.jsondocs/postman-collections/inji-certify-with-mock-identity.postman_environment.json
🧰 Additional context used
🪛 LanguageTool
docs/Presentation-During-Issuance.md
[style] ~9-~9: ‘necessary prerequisites’ might be wordy. Consider a shorter alternative.
Context: ...resentation, ensures the user meets the necessary prerequisites and provides cryptographically verifiab...
(EN_WORDINESS_PREMIUM_NECESSARY_PREREQUISITES)
[style] ~13-~13: Consider placing the discourse marker ‘first’ at the beginning of the sentence for more clarity.
Context: ...suer (Inji Certify), and a VP Verifier. The Wallet first discovers the Issuer's and auth server'...
(SENT_START_FIRST_PREMIUM)
[style] ~117-~117: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...irms VC is Valid (positive flow). 10. Inji Certify to Wallet: Responds with `200...
(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
- GitHub Check: build-maven-apitest-inji-certify / maven-build
- GitHub Check: build-maven-inji-certify / maven-build
- GitHub Check: Analyze (java-kotlin)
🔇 Additional comments (3)
docs/inji-certify-openapi.yaml (2)
1260-1279: LGTM!The OAuth 2.0 Authorization Server Metadata endpoint is properly defined following RFC 8414 conventions.
1616-1692: OAuth endpoints look well-structured.The
/oauth/iar,/oauth/token, and/oauth/.well-known/jwks.jsonendpoints follow standard OAuth/OpenID patterns with appropriate request/response schemas.docs/Presentation-During-Issuance.md (1)
1-133: Documentation is well-structured and comprehensive.The document clearly explains the Presentation During Issuance flow with:
- Clear problem statement and solution overview
- Well-defined actors
- Detailed sequence diagram
- Step-by-step phase breakdown
- References to relevant specifications
.../postman-collections/Inji Certify - Presentation During Issuance VCI.postman_collection.json
Show resolved
Hide resolved
.../postman-collections/Inji Certify - Presentation During Issuance VCI.postman_collection.json
Show resolved
Hide resolved
.../postman-collections/Inji Certify - Presentation During Issuance VCI.postman_collection.json
Show resolved
Hide resolved
.../postman-collections/Inji Certify - Presentation During Issuance VCI.postman_collection.json
Show resolved
Hide resolved
swatigoel
changed the title
Signed-off-by: Piyush7034 <piyushshukla2100@gmail.com>
There was a problem hiding this comment.
Actionable comments posted: 6
🤖 Fix all issues with AI agents
In @docs/inji-certify-openapi.yaml:
- Around line 2773-2779: The AuthorizationDetail schema (AuthorizationDetail) is
too minimal and must be expanded to match RFC 9396: make the `type` property
required and add documented optional properties such as `locations` (array of
strings or objects describing resource locations), `actions` (array of strings
listing permitted actions), and `datatypes` (array of strings describing
required datatypes), while keeping `credential_configuration_id`; include
concise descriptions and appropriate types for each property and ensure `type`
is listed in the schema's `required` array so validation enforces it.
- Around line 2858-2884: The TokenResponse schema is missing the OAuth-required
required fields; update the TokenResponse object definition to include a
required array listing "access_token" and "token_type" (e.g., add required:
["access_token","token_type"]) so those properties are enforced as mandatory in
the TokenResponse schema.
- Around line 2821-2841: AuthorizationSuccess schema lacks a required array; add
"required: [\"status\"]" to the AuthorizationSuccess object and document
conditional requirements for other properties (e.g., when status == "ok" require
"code", when status == "require_interaction" require "type" and
"openid4vp_request", when status == "error" require error details as
appropriate) so consumers know which fields must appear; update the
AuthorizationSuccess definition to reference the existing property names
(status, type, auth_session, openid4vp_request, code) and include the
conditional requirements in the schema description or via oneOf/anyOf with
discriminator on status if you want machine-enforceable validation.
- Around line 2842-2857: The OAuthTokenRequest schema is missing required
declarations; mark grant_type as required on OAuthTokenRequest and implement
conditional schemas for the two flows: create one subschema for
authorization_code where grant_type and code (and optionally code_verifier) are
required, and another subschema for refresh_token where grant_type and
refresh_token are required (use OpenAPI oneOf or discriminator to enforce these
conditions). Update the OAuthTokenRequest definition (referencing
OAuthTokenRequest, grant_type, code, code_verifier, refresh_token) to include
the top-level required: [grant_type] and add the oneOf block with the two
flow-specific required lists.
- Around line 2780-2820: Add a required array to the IarRequest schema listing
the mandatory fields: response_type, client_id, code_challenge, and
code_challenge_method (to reflect PKCE usage) and update the
authorization_details description to clarify that when using
application/x-www-form-urlencoded the authorization_details value must be a
JSON-encoded string (reference the IarRequest schema and the
authorization_details property to locate where to add the required array and
modify the description).
- Around line 2899-2943: The OpenAPI JWKS schema's exp field unit mismatches
JwksServiceImpl (which returns epoch seconds via toEpochSecond), and exp is not
a standard JWK member; either make both sides use seconds or explicitly treat it
as a custom field with a clear name and docs. Fix by updating the JWKS schema
entry (JWKS -> keys -> items) to document exp as seconds (or rename to
key_exp_time_sec) and/or change JwksServiceImpl to emit milliseconds
(toEpochMilli) to match the schema; add a code comment in JwksServiceImpl and an
OpenAPI description clarifying that this is a non-standard custom key property
if you keep the custom field, and ensure the property name does not conflict
with JWT's standard "exp" claim if you choose to rename it.
🧹 Nitpick comments (2)
docs/inji-certify-openapi.yaml (2)
1676-1692: Use consistent tag naming for JWKS endpoint.This endpoint is tagged as "o-auth-controller" which appears to be an auto-generated controller name and is inconsistent with other tags like "Well-known", "VC Issuance", etc. Consider changing the tag to "Well-known" for consistency, since this is a well-known endpoint.
♻️ Suggested change
/oauth/.well-known/jwks.json: get: tags: - - o-auth-controller + - Well-known summary: JSON Web Key Set description: Inji Certify's public keys for token verification
1616-1642: Inconsistent tag naming for OAuth endpoints.The /oauth/iar and /oauth/token endpoints are tagged as "o-auth-controller" which appears to be an auto-generated Spring controller name. This is inconsistent with the well-structured tags used elsewhere in the API (e.g., "Well-known", "VC Issuance", "Credential Configuration").
Consider using a more descriptive tag like "OAuth 2.0" or "Authorization" for better API documentation organization.
♻️ Suggested change
/oauth/iar: post: tags: - - o-auth-controller + - OAuth 2.0 summary: Interactive Authorization Request EndpointApply the same change to /oauth/token and /oauth/.well-known/jwks.json endpoints.
📜 Review details
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
docs/inji-certify-openapi.yaml
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
- GitHub Check: build-maven-inji-certify / maven-build
- GitHub Check: build-maven-apitest-inji-certify / maven-build
- GitHub Check: Analyze (java-kotlin)
🔇 Additional comments (2)
docs/inji-certify-openapi.yaml (2)
1260-1279: LGTM: OAuth Authorization Server metadata endpoint follows RFC 8414.The endpoint structure is correct and appropriately documented. The note clarifying the use of interactive authorization endpoint instead of the standard authorization_endpoint is helpful.
2397-2435: LGTM: OAuth AS metadata schema is well-structured.The schema correctly extends RFC 8414 OAuth Authorization Server metadata with the OpenID4VCI-specific
interactive_authorization_endpointfield. The required fields are appropriate for this implementation.
Signed-off-by: Piyush7034 <piyushshukla2100@gmail.com>
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Fix all issues with AI agents
In @docs/inji-certify-openapi.yaml:
- Around line 2397-2435: The OAuthAuthorizationServerMetadataDTO schema is
missing the jwks_uri field required by RFC 8414; update the
OAuthAuthorizationServerMetadataDTO definition to add jwks_uri to the required
list and add a jwks_uri property (type: string, format: uri) with a description
indicating it points to the JWKS endpoint (e.g., /oauth/.well-known/jwks.json)
so clients can retrieve keys to verify token signatures.
- Around line 2899-2913: The TokenError schema is missing a required declaration
for the error field; update the TokenError OpenAPI object to add a required
array that includes "error" so the schema enforces the presence of the error
property (i.e., modify the TokenError schema block to include required:
["error"] while keeping the existing properties error and error_description
unchanged).
🧹 Nitpick comments (3)
docs/inji-certify-openapi.yaml (3)
1616-1642: Inconsistent tag naming for OAuth endpoints.The tag
o-auth-controller(lines 1619, 1646, 1679) is inconsistent with other API tags like "Well-known", "VC Issuance", and "Credential Configuration" which use title case. Consider renaming to "OAuth" or "OAuth 2.0" for better consistency and user experience in API documentation.♻️ Proposed fix
/oauth/iar: post: tags: - - o-auth-controller + - OAuth summary: Interactive Authorization Request EndpointApply the same change to
/oauth/token(line 1646) and/oauth/.well-known/jwks.json(line 1679).
2812-2814: Clarify JSON encoding requirement for form-urlencoded fields.The
authorization_detailsfield description mentions "JSON containing RFC 9396 authorization details," but the schema shows it as an array of objects. Forapplication/x-www-form-urlencodedcontent type, this field must be submitted as a JSON-encoded string. Consider adding a note in the description to make this encoding requirement explicit for implementers.📋 Suggested enhancement
authorization_details: type: array items: type: object $ref: '#/components/schemas/AuthorizationDetail' description: | - JSON containing RFC 9396 authorization details - for requested credentials + RFC 9396 authorization details for requested credentials. + Note: When using application/x-www-form-urlencoded, this must be + submitted as a JSON-encoded string representation of the array.
2821-2847: Consider adding error fields for status="error" case.When
statusis "error", the schema doesn't define error-related fields. Consider adding optionalerroranderror_descriptionfields (per OAuth error response conventions) to provide details when authorization fails.📋 Suggested enhancement
code: type: string description: Authorization code to exchange for access token, sent in subsequent request once VP is submitted and verified successfully example: "SplxlOBeZQQYbYS6WxSbIA" + error: + type: string + description: Error code when status is "error" + error_description: + type: string + description: Human-readable error description when status is "error"
📜 Review details
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
docs/inji-certify-openapi.yaml
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
- GitHub Check: build-maven-inji-certify / maven-build
- GitHub Check: build-maven-apitest-inji-certify / maven-build
- GitHub Check: Analyze (java-kotlin)
🔇 Additional comments (4)
docs/inji-certify-openapi.yaml (4)
1260-1279: LGTM! OAuth AS metadata endpoint follows RFC 8414.The endpoint is correctly defined with appropriate description explaining why
authorization_endpointis omitted in favor of the interactive authorization endpoint.
1643-1675: LGTM! OAuth token endpoint correctly structured.The endpoint properly supports multiple grant types (authorization_code, pre-authorized_code, refresh_token) and has appropriate error handling with distinct response schemas for success and error cases.
1676-1692: LGTM! JWKS endpoint is properly defined.The endpoint correctly serves the JSON Web Key Set for token verification. Ensure this endpoint URL is referenced in the
jwks_urifield of the OAuth AS metadata (as flagged in a separate comment).
2868-2899: LGTM! TokenResponse schema correctly implements OAuth 2.0 and OpenID4VCI specs.The schema properly marks
access_tokenandtoken_typeas required per OAuth 2.0, and appropriately includes OpenID4VCI-specific fields (c_nonce,c_nonce_expires_in,authorization_details) for credential issuance flows.
… yaml Signed-off-by: Piyush7034 <piyushshukla2100@gmail.com>
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Fix all issues with AI agents
In
@certify-service/src/test/java/io/mosip/certify/controller/WellKnownControllerTest.java:
- Line 110: The test WellKnownControllerTest sets mockMetadata.setJwksUri(...)
but then asserts jwks_uri should not exist; change the assertion to verify
jwks_uri is present and equals the expected value: locate the mockMetadata setup
and the assertion (reference: mockMetadata, setJwksUri, jwks_uri) and replace
the "doesNotExist" assertion with an existence/equality check that the
response's jwks_uri equals
"http://localhost:8090/v1/certify/oauth/.well-known/jwks.json".
In
@certify-service/src/test/java/io/mosip/certify/services/OAuthAuthorizationServerMetadataServiceTest.java:
- Line 24: The test fails because setup() doesn't inject the jwksUri into the
service, so result.getJwksUri() returns null; fix by using
ReflectionTestUtils.setField in the setup() method to set the jwksUri field on
the OAuthAuthorizationServerMetadataService (or the tested instance) to the
TEST_JWKS_URI constant so the JWKS URI assertion passes — locate the setup()
method and add a
ReflectionTestUtils.setField(oauthAuthorizationServerMetadataService, "jwksUri",
TEST_JWKS_URI) call (using the same TEST_JWKS_URI defined in the test).
🧹 Nitpick comments (2)
docs/inji-certify-openapi.yaml (2)
1616-1642: Consider documenting error responses for IAR endpoint.The Interactive Authorization Request endpoint only defines a 200 success response. Consider adding error response schemas (e.g., 400 for invalid requests, 401 for unauthorized) to improve API documentation completeness and help client developers handle error cases.
📋 Suggested enhancement
responses: '200': description: Authorization successful content: application/json: schema: $ref: '#/components/schemas/AuthorizationSuccess' + '400': + description: Bad Request + content: + application/json: + schema: + type: object + properties: + error: + type: string + error_description: + type: string
2905-2919: Consider markingerrorfield as required in TokenError schema.Per OAuth 2.0 RFC 6749 Section 5.2, the
errorfield is required in token error responses. While the field is defined, adding it to arequiredarray would make the schema more explicit and enable better validation.📋 Suggested enhancement
TokenError: type: object + required: + - error properties: error: type: stringThis was noted in a previous review but remains unaddressed.
📜 Review details
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (7)
certify-core/src/main/java/io/mosip/certify/core/dto/OAuthAuthorizationServerMetadataDTO.javacertify-service/src/main/java/io/mosip/certify/services/OAuthAuthorizationServerMetadataService.javacertify-service/src/main/resources/application-local.propertiescertify-service/src/test/java/io/mosip/certify/controller/WellKnownControllerTest.javacertify-service/src/test/java/io/mosip/certify/services/OAuthAuthorizationServerMetadataServiceTest.javacertify-service/src/test/resources/application-test.propertiesdocs/inji-certify-openapi.yaml
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
- GitHub Check: build-maven-inji-certify / maven-build
- GitHub Check: build-maven-apitest-inji-certify / maven-build
- GitHub Check: Analyze (java-kotlin)
🔇 Additional comments (15)
certify-service/src/main/resources/application-local.properties (1)
275-275: LGTM!The JWKS URI configuration is correctly templated and follows the pattern of other OAuth metadata properties in this section.
certify-service/src/test/resources/application-test.properties (1)
114-114: LGTM!The transition to a templated domain URL improves maintainability and aligns with the configuration pattern used in application-local.properties.
certify-core/src/main/java/io/mosip/certify/core/dto/OAuthAuthorizationServerMetadataDTO.java (1)
35-36: LGTM!The new
jwksUrifield follows the existing patterns in the DTO and correctly maps to the OAuth standard field name using@JsonProperty("jwks_uri").certify-service/src/main/java/io/mosip/certify/services/OAuthAuthorizationServerMetadataService.java (2)
29-30: LGTM! JWKS URI configuration added correctly.The JWKS URI is properly injected via Spring's
@Valueannotation, consistent with other configuration properties in this service. The property will be validated at application startup.Note: Per RFC 8414,
jwks_uriis a recommended field for OAuth 2.0 Authorization Server Metadata, and it's essential for clients to verify token signatures.
55-55: LGTM! JWKS URI properly set in metadata.The JWKS URI is correctly propagated to the OAuth Authorization Server metadata DTO, completing the integration with the schema changes in the OpenAPI specification.
docs/inji-certify-openapi.yaml (10)
1260-1279: LGTM! OAuth AS metadata endpoint properly defined.The endpoint correctly implements RFC 8414's OAuth 2.0 Authorization Server Metadata discovery pattern. The description appropriately notes that
authorization_endpointis omitted in favor of the Interactive Authorization Request (IAR) endpoint, which is a valid extension point.
1643-1675: LGTM! Token endpoint properly documented.The OAuth 2.0 token endpoint is well-documented with proper request/response schemas and error handling. The endpoint supports multiple grant types as described.
1676-1692: LGTM! JWKS endpoint correctly defined.The JSON Web Key Set endpoint is properly configured to expose public keys for token verification, completing the OAuth 2.0 infrastructure.
2397-2441: LGTM! JWKS URI properly integrated into OAuth AS metadata schema.The
jwks_urifield has been correctly added to both the required fields list and the properties definition, addressing the RFC 8414 requirement. The schema is now complete for OAuth 2.0 Authorization Server Metadata.This resolves the previous review concern about the missing
jwks_urifield.
2779-2785: LGTM! AuthorizationDetail schema appropriate for use case.As clarified in previous review, this minimal schema aligns with the OpenID4VCI specification requirements for authorization details in credential requests.
2786-2826: LGTM! IarRequest schema supports dual-usage pattern.As explained in previous review, the lack of required fields is intentional to support both the initial OAuth 2.0 authorization request and the subsequent request with auth_session and openid4vp_response.
2827-2853: Well done! AuthorizationSuccess schema properly updated.The
statusfield is now correctly marked as required (line 2830), and the description clearly documents the conditional requirements based on status values. This addresses the previous review concern.
2854-2873: Well done! OAuthTokenRequest schema properly updated.The
grant_typefield is now correctly marked as required (line 2857) with an appropriate description, aligning with OAuth 2.0 specification requirements. This addresses the previous review concern.
2874-2904: LGTM! TokenResponse schema compliant with OAuth 2.0.The schema correctly marks
access_tokenandtoken_typeas required fields per RFC 6749, with appropriate descriptions and examples.
2920-2964: LGTM! JWKS schema comprehensive and well-documented.The JWKS schema includes all standard JWK parameters for various key types (RSA, EC) and additional fields like certificate chains and thumbprints. The schema properly supports token verification requirements.
certify-service/src/test/java/io/mosip/certify/controller/WellKnownControllerTest.java
Show resolved
Hide resolved
...ice/src/test/java/io/mosip/certify/services/OAuthAuthorizationServerMetadataServiceTest.java
Show resolved
Hide resolved
Signed-off-by: Piyush7034 <piyushshukla2100@gmail.com>
|
@coderabbitai resolve |
✅ Actions performedComments resolved. |
2 participants
Summary by CodeRabbit
Release Notes
New Features
Documentation
✏️ Tip: You can customize this high-level summary in your review settings.