feat: add consumer user management contract#30
Conversation
|
Wondering what really moved? Review this PR in Change Stack to inspect semantic changes, definitions, and references. Warning Review limit reached
More reviews will be available in 28 minutes. Learn how PR review limits work. Your organization has run out of usage credits. Purchase more in the billing tab. ⌛ How to resolve this issue?After more reviews become available, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans include higher PR review limits than trial, open-source, and free plans. In all cases, reviews become available again over time. During sustained high-volume PR review activity, CodeRabbit may temporarily slow when the next review becomes available. Please see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (67)
📝 WalkthroughWalkthroughRenames user-management tag, adds GET /openapi/v1/users/{userId}, supports optional operator query for user mutations, introduces typed consumer DTOs, and bumps version to 0.3.6 across specs, Java/Spring, Python, TypeScript, Rust, docs, and tests. ChangesUser Management contracts and typed consumer DTOs
Sequence Diagram(s)sequenceDiagram
participant Client as Client (Portal/Consumer)
participant SDK as SDKs (Java/Py/TS/Rust)
participant Server as Spring Boot 2
Client->>SDK: createOrUpdateUser(openUserDTO, operator?)
SDK->>Server: POST /openapi/v1/users?operator=...
Server-->>SDK: 200/403 per ManageUsers/portal rules
Client->>SDK: getUserByUserId(userId)
SDK->>Server: GET /openapi/v1/users/{userId}
Server-->>SDK: OpenUserInfoDTO
Estimated code review effort🎯 4 (Complex) | ⏱️ ~60 minutes Suggested reviewers
Poem
✨ Finishing Touches🧪 Generate unit tests (beta)
|
There was a problem hiding this comment.
Pull request overview
This PR updates the OpenAPI contract and regenerated client/server artifacts to support consumer-token user management operations and typed consumer management schemas, while renaming the user management tag/API surface from “Portal User Management” to “User Management”.
Changes:
- Renamed the User Management tag/API surface (Portal → User Management) and added
GET /openapi/v1/users/{userId}plusoperatorquery params for user mutations. - Introduced typed consumer management schemas (
OpenConsumerCreateRequestDTO,OpenConsumerInfoDTO) includingallowManageUsers, and updated consumers endpoints to use them. - Bumped generated artifacts/version strings to
0.3.6across TypeScript, Python, Rust, Java client, and Spring Boot 2 server outputs.
Reviewed changes
Copilot reviewed 96 out of 96 changed files in this pull request and generated 1 comment.
Show a summary per file
| File | Description |
|---|---|
| typescript/src/models/OpenConsumerInfoDTO.ts | New generated TS model for typed consumer info including allowManageUsers. |
| typescript/src/models/OpenConsumerCreateRequestDTO.ts | New generated TS model for typed consumer create request including allowManageUsers. |
| typescript/src/models/index.ts | Re-export new consumer DTO models from the TS models barrel. |
| typescript/src/apis/UserManagementApi.ts | Renamed TS API class and added operator query param + getUserByUserId endpoint support. |
| typescript/src/apis/PortalManagementApi.ts | Switched consumers endpoints to typed request/response DTOs in TS client. |
| typescript/src/apis/index.ts | Updated TS API barrel exports to UserManagementApi (and removed the old export). |
| typescript/README.md | Version bump to 0.3.6 in TS package README instructions. |
| typescript/package.json | Version bump to 0.3.6 for the TS package. |
| typescript/.openapi-generator/FILES | Updated TS generator file manifest for renamed/added artifacts. |
| tests/test_user_management_contract.py | Added contract tests ensuring tag rename + consumer manage-users requirements across specs. |
| spring-boot2/src/main/resources/openapi.yaml | Updated Spring server spec: tag rename, new user-by-id endpoint, operator params, typed consumer schemas. |
| spring-boot2/src/main/java/com/apollo/openapi/server/model/OpenConsumerInfoDTO.java | New generated Spring server model for consumer info (typed). |
| spring-boot2/src/main/java/com/apollo/openapi/server/model/OpenConsumerCreateRequestDTO.java | New generated Spring server model for consumer creation (typed). |
| spring-boot2/src/main/java/com/apollo/openapi/server/config/SpringDocConfiguration.java | Updated SpringDoc OpenAPI version string to 0.3.6. |
| spring-boot2/src/main/java/com/apollo/openapi/server/api/UserManagementApiDelegate.java | Renamed delegate interface and added new endpoint + operator params support (generated). |
| spring-boot2/src/main/java/com/apollo/openapi/server/api/UserManagementApiController.java | Renamed controller to UserManagementApiController (generated). |
| spring-boot2/src/main/java/com/apollo/openapi/server/api/UserManagementApi.java | Renamed API interface + added getUserByUserId and operator query params (generated). |
| spring-boot2/src/main/java/com/apollo/openapi/server/api/PortalManagementApiDelegate.java | Updated consumers methods to typed DTOs in Spring delegate (generated). |
| spring-boot2/src/main/java/com/apollo/openapi/server/api/PortalManagementApiController.java | Updated imports for typed consumer DTOs (generated). |
| spring-boot2/src/main/java/com/apollo/openapi/server/api/PortalManagementApi.java | Updated consumers methods to typed DTOs in Spring API interface (generated). |
| spring-boot2/pom.xml | Version bump to 0.3.6 for Spring Boot 2 server artifact. |
| spring-boot2/.openapi-generator/FILES | Updated Spring generator file manifest for renamed/added artifacts. |
| rust/src/models/open_consumer_info_dto.rs | New generated Rust model for typed consumer info including allow_manage_users. |
| rust/src/models/open_consumer_create_request_dto.rs | New generated Rust model for typed consumer create request including allow_manage_users. |
| rust/src/models/mod.rs | Export new Rust consumer DTO models from the module. |
| rust/src/apis/configuration.rs | Bumped Rust client User-Agent/version string to 0.3.6. |
| rust/README.md | Updated Rust README version references + model list for new DTOs. |
| rust/docs/OpenConsumerInfoDto.md | Added Rust docs page for OpenConsumerInfoDto. |
| rust/docs/OpenConsumerCreateRequestDto.md | Added Rust docs page for OpenConsumerCreateRequestDto. |
| rust/Cargo.toml | Version bump to 0.3.6 for the Rust crate. |
| rust/.openapi-generator/FILES | Updated Rust generator file manifest for new docs/models. |
| python/test/test_paths/test_openapi_v1_users/test_post.py | Updated generated Python path test description text for renamed user operations. |
| python/test/test_paths/test_openapi_v1_users/test_get.py | Updated generated Python path test description text for renamed user operations. |
| python/test/test_paths/test_openapi_v1_users_user_id/test_get.py | Added generated Python test stub for the new user-by-id endpoint. |
| python/test/test_paths/test_openapi_v1_users_user_id/init.py | Added package init for new generated Python path test module. |
| python/test/test_paths/test_openapi_v1_users_enabled/test_put.py | Updated generated Python path test description text for renamed user operations. |
| python/test/test_models/test_open_consumer_info_dto.py | Added generated Python model test stub for OpenConsumerInfoDTO. |
| python/test/test_models/test_open_consumer_create_request_dto.py | Added generated Python model test stub for OpenConsumerCreateRequestDTO. |
| python/setup.py | Version bump to 0.3.6 for the Python package. |
| python/README.md | Updated Python README API/package versions and API/tag listings for renamed user management + new DTOs. |
| python/docs/models/OpenConsumerInfoDTO.md | Added Python docs for OpenConsumerInfoDTO. |
| python/docs/models/OpenConsumerCreateRequestDTO.md | Added Python docs for OpenConsumerCreateRequestDTO. |
| python/docs/apis/tags/PortalManagementApi.md | Updated Python docs: consumers endpoints now use typed request/response DTOs. |
| python/apollo_openapi/paths/openapi_v1_users/post.pyi | Added operator query parameter typing for generated Python stub. |
| python/apollo_openapi/paths/openapi_v1_users/post.py | Added operator query parameter handling for generated Python implementation. |
| python/apollo_openapi/paths/openapi_v1_users/get.pyi | Updated generated Python stub docstring for renamed user search operation. |
| python/apollo_openapi/paths/openapi_v1_users/get.py | Updated generated Python implementation docstring for renamed user search operation. |
| python/apollo_openapi/paths/openapi_v1_users_user_id/get.pyi | Added generated Python stub for the new user-by-id endpoint. |
| python/apollo_openapi/paths/openapi_v1_users_user_id/init.py | Added generated Python path module for user-by-id endpoint. |
| python/apollo_openapi/paths/openapi_v1_users_enabled/put.pyi | Added operator query parameter typing + plumbing for change-enabled endpoint stub. |
| python/apollo_openapi/paths/openapi_v1_users_enabled/put.py | Added operator query parameter handling for change-enabled endpoint implementation. |
| python/apollo_openapi/paths/openapi_v1_consumers/post.pyi | Updated consumers create endpoint typing to use typed consumer DTOs. |
| python/apollo_openapi/paths/openapi_v1_consumers/post.py | Updated consumers create endpoint implementation to use typed consumer DTOs. |
| python/apollo_openapi/paths/openapi_v1_consumers/get.pyi | Updated consumers list endpoint response typing to OpenConsumerInfoDTO. |
| python/apollo_openapi/paths/openapi_v1_consumers/get.py | Updated consumers list endpoint response typing to OpenConsumerInfoDTO. |
| python/apollo_openapi/paths/init.py | Added path enum entry for /openapi/v1/users/{userId}. |
| python/apollo_openapi/models/init.py | Export new Python consumer DTO models. |
| python/apollo_openapi/model/open_consumer_info_dto.pyi | Added generated Python stub model for OpenConsumerInfoDTO. |
| python/apollo_openapi/model/open_consumer_info_dto.py | Added generated Python runtime model for OpenConsumerInfoDTO. |
| python/apollo_openapi/model/open_consumer_create_request_dto.pyi | Added generated Python stub model for OpenConsumerCreateRequestDTO. |
| python/apollo_openapi/model/open_consumer_create_request_dto.py | Added generated Python runtime model for OpenConsumerCreateRequestDTO. |
| python/apollo_openapi/configuration.py | Updated Python SDK debug report versions to 0.3.6. |
| python/apollo_openapi/apis/tags/user_management_api.py | Renamed generated tag API wrapper class and added GetUserByUserId mixin. |
| python/apollo_openapi/apis/tags/init.py | Renamed tag enum value to USER_MANAGEMENT. |
| python/apollo_openapi/apis/tag_to_api.py | Updated tag-to-API mapping for renamed user management API class. |
| python/apollo_openapi/apis/paths/openapi_v1_users_user_id.py | Added generated API path wrapper for /openapi/v1/users/{userId}. |
| python/apollo_openapi/apis/path_to_api.py | Added path-to-API mapping for the new user-by-id endpoint. |
| python/apollo_openapi/api_client.py | Updated Python client User-Agent/version to 0.3.6. |
| python/apollo_openapi/init.py | Updated Python package __version__ to 0.3.6. |
| python/.openapi-generator/FILES | Updated Python generator file manifest for renamed/added artifacts. |
| java-client/src/test/java/org/openapitools/client/model/OpenConsumerInfoDTOTest.java | Added generated Java client model test stub for OpenConsumerInfoDTO. |
| java-client/src/test/java/org/openapitools/client/model/OpenConsumerCreateRequestDTOTest.java | Added generated Java client model test stub for OpenConsumerCreateRequestDTO. |
| java-client/src/test/java/org/openapitools/client/api/UserManagementApiTest.java | Renamed Java client API test stub and added coverage for getUserByUserId + operator params. |
| java-client/src/test/java/org/openapitools/client/api/PortalManagementApiTest.java | Updated Java client test stub types for consumers endpoints to use typed DTOs. |
| java-client/src/main/java/org/openapitools/client/JSON.java | Registered Gson type adapter factories for new Java client consumer DTO models. |
| java-client/src/main/java/org/openapitools/client/Configuration.java | Updated Java client SDK version constant to 0.3.6. |
| java-client/src/main/java/org/openapitools/client/ApiClient.java | Updated Java client User-Agent/version string to 0.3.6. |
| java-client/src/main/java/org/openapitools/client/api/PortalManagementApi.java | Updated Java client consumers methods to typed DTOs. |
| java-client/README.md | Updated Java client README API version and API list for renamed user management + new DTOs. |
| java-client/pom.xml | Version bump to 0.3.6 for Java client artifact. |
| java-client/docs/UserManagementApi.md | Updated Java docs for renamed UserManagement API and new endpoint/operator params. |
| java-client/docs/PortalManagementApi.md | Updated Java docs for consumers endpoints to typed DTOs. |
| java-client/docs/OpenConsumerInfoDTO.md | Added Java docs page for OpenConsumerInfoDTO. |
| java-client/docs/OpenConsumerCreateRequestDTO.md | Added Java docs page for OpenConsumerCreateRequestDTO. |
| java-client/build.sbt | Version bump to 0.3.6 for SBT build metadata. |
| java-client/build.gradle | Version bump to 0.3.6 for Gradle build metadata. |
| java-client/api/openapi.yaml | Updated Java-client embedded spec for tag rename, new endpoint, operator params, typed consumer schemas. |
| java-client/.openapi-generator/FILES | Updated Java generator file manifest for renamed/added artifacts. |
| generate.sh | Updated generator script to emit 0.3.6 artifacts across languages. |
| CHANGELOG.md | Documented the tag/API rename and added consumer manage-users + typed consumer schemas under Unreleased. |
| apollo-openapi.yaml | Updated root OpenAPI spec for tag rename, new endpoint, operator params, and typed consumer schemas. |
Comments suppressed due to low confidence (2)
spring-boot2/src/main/java/com/apollo/openapi/server/api/UserManagementApiDelegate.java:19
- Javadoc link has an extra closing brace (
{@link UserManagementApiController}}), which breaks the inline tag syntax and can trigger doclint/javadoc warnings (and in some builds, failures).
typescript/src/apis/index.ts:18 - Removing the
PortalUserManagementApiexport is a breaking change for existing SDK consumers. If the intent is a rename only, consider keeping a deprecated alias export so old imports continue to work (at least for the API class).
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 13f9651de9
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
There was a problem hiding this comment.
Actionable comments posted: 6
Note
Due to the large number of review comments, Critical, Major severity comments were prioritized as inline comments.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
apollo-openapi.yaml (1)
5375-5382:⚠️ Potential issue | 🟠 Major | 🏗️ Heavy liftPrevent token leakage in consumer list responses.
GET /openapi/v1/consumersreturnsOpenConsumerInfoDTO, and that schema includestoken. This makes token disclosure part of the list contract and can expose credentials at scale.Suggested contract shape
/openapi/v1/consumers: get: @@ application/json: schema: type: array items: - $ref: '`#/components/schemas/OpenConsumerInfoDTO`' + $ref: '`#/components/schemas/OpenConsumerListItemDTO`' @@ + OpenConsumerListItemDTO: + type: object + properties: + appId: + type: string + name: + type: string + orgId: + type: string + orgName: + type: string + ownerName: + type: string + ownerEmail: + type: string + consumerId: + type: integer + format: int64 + allowCreateApplication: + type: boolean + default: false + allowManageUsers: + type: boolean + default: false + rateLimit: + type: integer + default: 0Also applies to: 6861-6889
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@apollo-openapi.yaml` around lines 5375 - 5382, The consumer list response currently exposes secret tokens by returning OpenConsumerInfoDTO for GET /openapi/v1/consumers; change the contract to return a safe summary schema (e.g., create OpenConsumerSummaryDTO that omits token and any credentials) and update the response items $ref to '`#/components/schemas/OpenConsumerSummaryDTO`' instead of OpenConsumerInfoDTO; also apply the same replacement for the other affected list endpoints that currently reference OpenConsumerInfoDTO so tokens are not leaked at scale.
🟡 Minor comments (17)
apollo-openapi.yaml-6857-6860 (1)
6857-6860:⚠️ Potential issue | 🟡 Minor | ⚡ Quick winConstrain
rateLimitto non-negative values.The schema description says
0means unlimited, but negative values are currently valid by contract.Suggested fix
rateLimit: type: integer description: 限流QPS,0表示不限流 default: 0 + minimum: 0 @@ rateLimit: type: integer description: 限流QPS,0表示不限流 default: 0 + minimum: 0Also applies to: 6897-6900
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@apollo-openapi.yaml` around lines 6857 - 6860, The rateLimit integer schema currently allows negative values even though 0 means unlimited; update the rateLimit schema (the property named "rateLimit") to constrain values to non-negative by adding a minimum: 0 (or minimum: 0 and exclusiveMinimum: false) so negatives are rejected, and apply the same change to the second occurrence of the rateLimit schema referenced in the comment.spring-boot2/src/main/java/com/apollo/openapi/server/api/UserManagementApiDelegate.java-18-18 (1)
18-18:⚠️ Potential issue | 🟡 Minor | ⚡ Quick winFix malformed Javadoc link in interface header.
There is an extra
}in the link target, which breaks the Javadoc reference.Suggested fix
- * A delegate to be called by the {`@link` UserManagementApiController}}. + * A delegate to be called by the {`@link` UserManagementApiController}.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@spring-boot2/src/main/java/com/apollo/openapi/server/api/UserManagementApiDelegate.java` at line 18, The class/interface Javadoc for UserManagementApiDelegate contains a malformed link "{`@link` UserManagementApiController}}" with an extra closing brace; edit the Javadoc comment for UserManagementApiDelegate and change the link to "{`@link` UserManagementApiController}" (remove the extra "}") so the {`@link` UserManagementApiController} reference resolves correctly.python/apollo_openapi/paths/openapi_v1_consumers/get.pyi-79-79 (1)
79-79:⚠️ Potential issue | 🟡 MinorFix tuple typing for list-schema constructor input (Line 79)
Line 79 usestyping.Tuple['OpenConsumerInfoDTO'], which denotes a fixed 1-element tuple; to match variable-length tuple/list inputs, change it totyping.Tuple['OpenConsumerInfoDTO', ...].🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@python/apollo_openapi/paths/openapi_v1_consumers/get.pyi` at line 79, The _arg type annotation for the list-schema constructor uses a fixed-length tuple form for OpenConsumerInfoDTO; update the annotation for _arg (the union branch that currently has typing.Tuple['OpenConsumerInfoDTO']) to the variable-length tuple form (use Tuple with an ellipsis) so it accepts arbitrary-length tuples/lists of OpenConsumerInfoDTO instead of only a single-element tuple.java-client/docs/UserManagementApi.md-291-297 (1)
291-297:⚠️ Potential issue | 🟡 Minor | ⚡ Quick winAdd blank lines around the new response-details table.
The table starting at Line 292 is not surrounded by blank lines (
MD058).Proposed diff
### HTTP response details + | Status code | Description | Response headers | |-------------|-------------|------------------| | **200** | 成功获取用户 | - | | **400** | 请求参数错误或用户不存在 | - | | **403** | 权限不足 | - | +🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@java-client/docs/UserManagementApi.md` around lines 291 - 297, Add a blank line before and after the "HTTP response details" table in UserManagementApi.md (the table under the "### HTTP response details" heading) so the Markdown table is separated by empty lines and satisfies MD058; ensure there is one empty line between the heading and the table and one empty line after the table.Source: Linters/SAST tools
java-client/docs/UserManagementApi.md-235-291 (1)
235-291:⚠️ Potential issue | 🟡 Minor | ⚡ Quick winFix heading-level jump in the new
getUserByUserIdblock.Line 235 starts with
###directly under an H1 section (Line 228), which triggers markdownlintMD001. Keep subsection levels incrementing by one.Proposed diff
-### Example +## Example @@ -### Parameters +## Parameters @@ -### Return type +## Return type @@ -### Authorization +## Authorization @@ -### HTTP request headers +## HTTP request headers @@ -### HTTP response details +## HTTP response details🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@java-client/docs/UserManagementApi.md` around lines 235 - 291, The new getUserByUserId section uses H3 (###) directly under an H1, triggering MD001; update the heading levels in the getUserByUserId block (e.g., change "### Example", "### Parameters", "### Return type", "### Authorization", "### HTTP request headers", "### HTTP response details") to be one level higher (use "##" instead of "###") so subsections increment correctly under the top-level H1; locate headings around the getUserByUserId examples and adjust them accordingly.Source: Linters/SAST tools
python/docs/apis/tags/PortalManagementApi.md-624-627 (1)
624-627:⚠️ Potential issue | 🟡 Minor | ⚡ Quick winFix malformed schema tables in the new typed DTO sections.
Line 624 and Line 661 start tables where the data rows currently have too few cells for the declared columns, which breaks markdownlint and can render incorrectly.
🔧 Suggested fix
### body # SchemaForRequestBodyApplicationJson + Type | Description | Notes ------------- | ------------- | ------------- -[**OpenConsumerCreateRequestDTO**](../../models/OpenConsumerCreateRequestDTO.md) | | +[**OpenConsumerCreateRequestDTO**](../../models/OpenConsumerCreateRequestDTO.md) | | | @@ # SchemaFor200ResponseBodyApplicationJson + Type | Description | Notes ------------- | ------------- | ------------- -[**OpenConsumerInfoDTO**](../../models/OpenConsumerInfoDTO.md) | | +[**OpenConsumerInfoDTO**](../../models/OpenConsumerInfoDTO.md) | | |Also applies to: 661-664
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@python/docs/apis/tags/PortalManagementApi.md` around lines 624 - 627, The table rows in the typed DTO sections (e.g., the row referencing OpenConsumerCreateRequestDTO) have fewer cells than the header (Type | Description | Notes); update each malformed row so it has three pipe-separated cells — for example " [**OpenConsumerCreateRequestDTO**](../../models/OpenConsumerCreateRequestDTO.md) | | " or provide text for Description/Notes — ensuring every data row matches the header column count in the PortalManagementApi.md typed DTO tables.Source: Linters/SAST tools
python/docs/apis/tags/PortalManagementApi.md-3084-3084 (1)
3084-3084:⚠️ Potential issue | 🟡 Minor | ⚡ Quick winReplace unresolved template token in tuple-item doc links.
Line 3084 still contains
{{complexTypePrefix}}, which renders as a broken path in published docs and also leaves the row one column short.🔧 Suggested fix
-[**OpenConsumerInfoDTO**]({{complexTypePrefix}}OpenConsumerInfoDTO.md) | [**OpenConsumerInfoDTO**]({{complexTypePrefix}}OpenConsumerInfoDTO.md) | [**OpenConsumerInfoDTO**]({{complexTypePrefix}}OpenConsumerInfoDTO.md) | | +[**OpenConsumerInfoDTO**](../../models/OpenConsumerInfoDTO.md) | [**OpenConsumerInfoDTO**](../../models/OpenConsumerInfoDTO.md) | [**OpenConsumerInfoDTO**](../../models/OpenConsumerInfoDTO.md) | | |🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@python/docs/apis/tags/PortalManagementApi.md` at line 3084, The table row containing the three links to OpenConsumerInfoDTO still has the unresolved token "{{complexTypePrefix}}" and is missing the fourth column; update the three link targets in the row (the occurrences of "{{complexTypePrefix}}OpenConsumerInfoDTO.md") to the correct target (e.g., "OpenConsumerInfoDTO.md" or the actual complexTypePrefix value used elsewhere) and restore the fourth column (add a meaningful cell or a placeholder like "-" or "N/A") so the row renders with four columns; locate the row by the link text "OpenConsumerInfoDTO" to apply the change.Source: Linters/SAST tools
python/docs/apis/tags/UserManagementApi.md-526-528 (1)
526-528:⚠️ Potential issue | 🟡 Minor | ⚡ Quick winFix broken in-page response links for
get_user_by_user_id.Line 526–Line 528 use fragment targets that markdownlint marks as invalid, so readers cannot jump to the response sections reliably.
🔧 Suggested fix
-200 | [ApiResponseFor200](`#get_user_by_user_id.ApiResponseFor200`) | 成功获取用户 -400 | [ApiResponseFor400](`#get_user_by_user_id.ApiResponseFor400`) | 请求参数错误或用户不存在 -403 | [ApiResponseFor403](`#get_user_by_user_id.ApiResponseFor403`) | 权限不足 +200 | [ApiResponseFor200](`#get_user_by_user_idapiresponsefor200`) | 成功获取用户 +400 | [ApiResponseFor400](`#get_user_by_user_idapiresponsefor400`) | 请求参数错误或用户不存在 +403 | [ApiResponseFor403](`#get_user_by_user_idapiresponsefor403`) | 权限不足🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@python/docs/apis/tags/UserManagementApi.md` around lines 526 - 528, The in-page response links for get_user_by_user_id are using invalid fragment targets (e.g. "`#get_user_by_user_id.ApiResponseFor200`", "`#get_user_by_user_id.ApiResponseFor400`", "`#get_user_by_user_id.ApiResponseFor403`"); open the markdown, locate the actual headings for the ApiResponseFor200/ApiResponseFor400/ApiResponseFor403 sections under get_user_by_user_id, copy the exact rendered anchor IDs for those headings and replace the broken fragments with those exact anchors so the links resolve correctly (update the three link targets that reference ApiResponseFor200/400/403).Source: Linters/SAST tools
python/docs/models/OpenConsumerCreateRequestDTO.md-4-6 (1)
4-6:⚠️ Potential issue | 🟡 Minor | ⚡ Quick winCorrect the
Model Type Infotable row shape.Line 6 currently has fewer cells than the header declares, which triggers markdownlint and can render inconsistently.
🔧 Suggested fix
## Model Type Info + Input Type | Accessed Type | Description | Notes ------------ | ------------- | ------------- | ------------- -dict, frozendict.frozendict, | frozendict.frozendict, | | +dict, frozendict.frozendict, | frozendict.frozendict, | | |🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@python/docs/models/OpenConsumerCreateRequestDTO.md` around lines 4 - 6, The table row under "Model Type Info" has only three cells causing a markdown table shape error; update the row that currently starts with "dict, frozendict.frozendict," so it has four pipe-separated cells to match the header (Input Type | Accessed Type | Description | Notes), e.g., add an extra trailing " | " to create the missing empty cell(s) or fill them with the appropriate Description/Notes text for OpenConsumerCreateRequestDTO.Source: Linters/SAST tools
python/docs/models/OpenConsumerInfoDTO.md-4-6 (1)
4-6:⚠️ Potential issue | 🟡 Minor | ⚡ Quick winFix malformed
Model Type Infotable row.Line 6 is missing one column value relative to the header, causing markdownlint failures and poor rendering in some viewers.
🔧 Suggested fix
## Model Type Info + Input Type | Accessed Type | Description | Notes ------------ | ------------- | ------------- | ------------- -dict, frozendict.frozendict, | frozendict.frozendict, | | +dict, frozendict.frozendict, | frozendict.frozendict, | | |🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@python/docs/models/OpenConsumerInfoDTO.md` around lines 4 - 6, The table row under the "Model Type Info" header in OpenConsumerInfoDTO.md has only three pipe-separated columns, causing markdown errors; update the offending row (the line starting with "dict, frozendict.frozendict, | frozendict.frozendict, |") to include the missing fourth column so it has four columns matching the header "Input Type | Accessed Type | Description | Notes" (you can add an empty value or appropriate note in the fourth column).Source: Linters/SAST tools
rust/docs/OpenConsumerInfoDto.md-15-17 (1)
15-17:⚠️ Potential issue | 🟡 Minor | ⚡ Quick winFix broken markdown reference formatting in property notes.
[optional][default to false]and[default to 0]are parsed as reference links with missing definitions, so docs render incorrectly.Suggested doc fix
-**allow_create_application** | Option<**bool**> | 是否允许该Consumer Token创建应用 | [optional][default to false] -**allow_manage_users** | Option<**bool**> | 是否允许该Consumer Token管理用户 | [optional][default to false] -**rate_limit** | Option<**i32**> | 限流QPS,0表示不限流 | [optional][default to 0] +**allow_create_application** | Option<**bool**> | 是否允许该Consumer Token创建应用 | optional, default: false +**allow_manage_users** | Option<**bool**> | 是否允许该Consumer Token管理用户 | optional, default: false +**rate_limit** | Option<**i32**> | 限流QPS,0表示不限流 | optional, default: 0🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@rust/docs/OpenConsumerInfoDto.md` around lines 15 - 17, The property notes in OpenConsumerInfoDto.md use bracketed tokens like "[optional][default to false]" which are parsed as reference links; update the three property lines for allow_create_application, allow_manage_users, and rate_limit to use inline plain text or parentheses (e.g. "(optional, default: false)" and "(optional, default: 0)") instead of bracketed reference syntax so the docs render correctly.Source: Linters/SAST tools
java-client/src/main/java/org/openapitools/client/model/OpenConsumerInfoDTO.java-419-427 (1)
419-427:⚠️ Potential issue | 🟡 Minor | ⚡ Quick winReturn early after handling
nullinvalidateJsonObject.Line 426 dereferences
jsonObjeven when Line 420 allows it to benull(no required fields), which can throw aNullPointerExceptionon valid nullable input paths.💡 Suggested fix
public static void validateJsonObject(JsonObject jsonObj) throws IOException { if (jsonObj == null) { if (!OpenConsumerInfoDTO.openapiRequiredFields.isEmpty()) { // has required fields but JSON object is null throw new IllegalArgumentException(String.format("The required field(s) %s in OpenConsumerInfoDTO is not found in the empty JSON string", OpenConsumerInfoDTO.openapiRequiredFields.toString())); } + return; } Set<Entry<String, JsonElement>> entries = jsonObj.entrySet();🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@java-client/src/main/java/org/openapitools/client/model/OpenConsumerInfoDTO.java` around lines 419 - 427, In validateJsonObject, after checking jsonObj == null and handling required fields with OpenConsumerInfoDTO.openapiRequiredFields, return immediately when jsonObj is null (and no required fields) to avoid dereferencing jsonObj; that is, ensure the method exits before reaching the line that computes Set<Entry<String, JsonElement>> entries = jsonObj.entrySet(); so subsequent code only runs when jsonObj is non-null.java-client/src/test/java/org/openapitools/client/model/OpenConsumerCreateRequestDTOTest.java-34-109 (1)
34-109:⚠️ Potential issue | 🟡 Minor | ⚡ Quick winThese test methods currently pass without testing anything.
All methods are annotated with
@Testbut contain only TODOs, so the suite reports green without coverage for this DTO behavior.💡 Suggested fix
+@Disabled("Generated test stubs: enable after adding assertions") public class OpenConsumerCreateRequestDTOTest {🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@java-client/src/test/java/org/openapitools/client/model/OpenConsumerCreateRequestDTOTest.java` around lines 34 - 109, Replace the TODOs with real assertions: instantiate OpenConsumerCreateRequestDTO, set example values for each field (appId, allowCreateApplication, allowManageUsers, name, orgId, orgName, ownerName, rateLimitEnabled, rateLimit) using the DTO's setters, then assert the corresponding getters return the same values (use Assert.assertEquals / assertTrue as appropriate) inside testOpenConsumerCreateRequestDTO and/or in each specific test method (appIdTest, allowCreateApplicationTest, allowManageUsersTest, nameTest, orgIdTest, orgNameTest, ownerNameTest, rateLimitEnabledTest, rateLimitTest); optionally add simple assertions for toString()/equals()/hashCode() on the populated instance to increase coverage.java-client/src/test/java/org/openapitools/client/model/OpenConsumerInfoDTOTest.java-34-125 (1)
34-125:⚠️ Potential issue | 🟡 Minor | ⚡ Quick winThese test methods are TODO stubs and currently vacuous.
The class reports passing tests without asserting model behavior, which weakens regression detection for the new DTO contract.
💡 Suggested fix
+@Disabled("Generated test stubs: enable after adding assertions") public class OpenConsumerInfoDTOTest {🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@java-client/src/test/java/org/openapitools/client/model/OpenConsumerInfoDTOTest.java` around lines 34 - 125, Replace the TODO stubs in OpenConsumerInfoDTOTest by building a real OpenConsumerInfoDTO instance in testOpenConsumerInfoDTO and in each property test (appIdTest, nameTest, orgIdTest, orgNameTest, ownerNameTest, ownerEmailTest, consumerIdTest, tokenTest, allowCreateApplicationTest, allowManageUsersTest, rateLimitTest) set the corresponding field (via constructor or setters) and assert expected behavior using JUnit assertions (e.g., assertEquals for getter values, assertNotNull where appropriate); also add a simple equality/hashCode/toString check in testOpenConsumerInfoDTO to validate model contract.rust/docs/OpenConsumerCreateRequestDto.md-8-9 (1)
8-9:⚠️ Potential issue | 🟡 Minor | ⚡ Quick winFix undefined reference-style labels in Notes column.
Line 8, Line 9, Line 14, and Line 15 use
[...]text that Markdown parses as reference links, but no link definitions exist. This can break markdownlint and doc rendering.Suggested patch
-**allow_create_application** | Option<**bool**> | 是否允许该Consumer Token创建应用 | [optional][default to false] -**allow_manage_users** | Option<**bool**> | 是否允许该Consumer Token管理用户 | [optional][default to false] +**allow_create_application** | Option<**bool**> | 是否允许该Consumer Token创建应用 | optional, default: false +**allow_manage_users** | Option<**bool**> | 是否允许该Consumer Token管理用户 | optional, default: false ... -**rate_limit_enabled** | Option<**bool**> | 是否开启限流 | [optional][default to false] -**rate_limit** | Option<**i32**> | 限流QPS,0表示不限流 | [optional][default to 0] +**rate_limit_enabled** | Option<**bool**> | 是否开启限流 | optional, default: false +**rate_limit** | Option<**i32**> | 限流QPS,0表示不限流 | optional, default: 0Also applies to: 14-15
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@rust/docs/OpenConsumerCreateRequestDto.md` around lines 8 - 9, The Notes column uses reference-style bracket text like "[optional][default to false]" which creates undefined Markdown links; update occurrences for the fields allow_create_application and allow_manage_users (and the similar occurrences around lines for the other two fields) to a non-reference form such as "(optional, default to false)" or "optional — default: false" so the text isn't parsed as a reference link; ensure all four instances are changed consistently.Source: Linters/SAST tools
spring-boot2/src/main/resources/openapi.yaml-5966-5983 (1)
5966-5983:⚠️ Potential issue | 🟡 Minor | ⚡ Quick winDocument the unauthenticated failure path on
getUserByUserId.
GET /openapi/v1/usersalready advertises401and403for the same auth surface, but the newGET /openapi/v1/users/{userId}only documents400/403. That makes sibling user-management operations inconsistent in every generated SDK and leaves a normal unauthenticated response undocumented on this method.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@spring-boot2/src/main/resources/openapi.yaml` around lines 5966 - 5983, The getUserByUserId OpenAPI operation is missing the 401 unauthenticated response; update the OpenAPI entry for GET /openapi/v1/users/{userId} (the operation that currently lists "200", "400", "403") to include a "401" response using the same ExceptionResponse schema as the other user endpoints so unauthenticated failure is documented consistently with the GET /openapi/v1/users operation.tests/test_user_management_contract.py-19-20 (1)
19-20:⚠️ Potential issue | 🟡 Minor | ⚡ Quick winForce UTF-8 when loading the specs.
These YAML files contain non-ASCII text, so
read_text()currently depends on the host default codec. On Windows-style locales this can fail withUnicodeDecodeErrorbefore the contract assertions run. Passencoding="utf-8"here.Suggested fix
def _load_spec(self, spec_file): - return yaml.safe_load((self.repo_root / spec_file).read_text()) + return yaml.safe_load((self.repo_root / spec_file).read_text(encoding="utf-8"))🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@tests/test_user_management_contract.py` around lines 19 - 20, The _load_spec method uses (self.repo_root / spec_file).read_text() which relies on the system default encoding and can raise UnicodeDecodeError for non-ASCII YAML; change the call to read_text(encoding="utf-8") so yaml.safe_load always gets UTF‑8 decoded text (update the _load_spec function accordingly).
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In
`@java-client/src/main/java/org/openapitools/client/model/OpenConsumerCreateRequestDTO.java`:
- Around line 364-370: The null-check in
OpenConsumerCreateRequestDTO.validateJsonObject is incomplete: if jsonObj is
null and there are no required fields the method falls through and dereferences
jsonObj.entrySet(), causing an NPE; update validateJsonObject (in class
OpenConsumerCreateRequestDTO) to return early when jsonObj == null (after
handling required-fields logic) so the method does not continue to call
jsonObj.entrySet() on a null reference.
In
`@java-client/src/main/java/org/openapitools/client/model/OpenConsumerInfoDTO.java`:
- Around line 361-375: The toString() in OpenConsumerInfoDTO currently appends
the raw token (field token) which risks credential/PII leakage; update
OpenConsumerInfoDTO.toString() to omit or redact the token (e.g., replace with
"[REDACTED]" or not include the token field at all) while leaving other fields
unchanged, and ensure any helper toIndentedString usage for token is replaced
accordingly so logs will never output the cleartext token.
In `@python/apollo_openapi/apis/tags/__init__.py`:
- Around line 22-23: The rename removed the old enum member used by clients
(TagValues.PORTAL_USER_MANAGEMENT); restore backward compatibility by adding a
deprecated alias: define PORTAL_USER_MANAGEMENT = PORTAL_MANAGEMENT alongside
the new constant in the same module
(python/apollo_openapi/apis/tags/__init__.py), add a brief comment marking it
deprecated and keep it exported so existing imports continue to work for at
least one minor release.
In
`@spring-boot2/src/main/java/com/apollo/openapi/server/model/OpenConsumerInfoDTO.java`:
- Around line 294-305: The OpenConsumerInfoDTO.toString() currently includes the
sensitive field token; update the toString() method (in class
OpenConsumerInfoDTO) to avoid leaking credentials by either omitting the token
line or replacing its value with a fixed redaction string (e.g., "<redacted>")
instead of calling toIndentedString(token); ensure only the token line is
changed (leave other fields and toIndentedString usage intact) so logs no longer
contain the raw token.
In `@spring-boot2/src/main/resources/openapi.yaml`:
- Around line 6392-6395: The current OpenAPI uses OpenConsumerInfoDTO (which
contains the token) as the response schema for the consumers list (GET
/openapi/v1/consumers), which leaks credentials; create a new schema (e.g.,
OpenConsumerSummaryDTO or OpenConsumerListItem) that omits the token field and
replace all array responses that reference OpenConsumerInfoDTO for list
endpoints (including the GET /openapi/v1/consumers entry and the other
occurrences around lines noted) to reference the new schema, leaving
OpenConsumerInfoDTO intact for detail/create/token endpoints (such as
/openapi/v1/consumer-tokens/by-appId).
In `@typescript/src/apis/UserManagementApi.ts`:
- Line 55: The exported class was renamed to UserManagementApi which breaks
existing consumers using PortalUserManagementApi; restore a backward-compatible
alias by exporting PortalUserManagementApi as a deprecated reference to
UserManagementApi (e.g., add an export or const/typedef named
PortalUserManagementApi that points to UserManagementApi and mark it deprecated
in a comment), so both UserManagementApi and PortalUserManagementApi resolve to
the same class without changing runtime behavior.
---
Outside diff comments:
In `@apollo-openapi.yaml`:
- Around line 5375-5382: The consumer list response currently exposes secret
tokens by returning OpenConsumerInfoDTO for GET /openapi/v1/consumers; change
the contract to return a safe summary schema (e.g., create
OpenConsumerSummaryDTO that omits token and any credentials) and update the
response items $ref to '`#/components/schemas/OpenConsumerSummaryDTO`' instead of
OpenConsumerInfoDTO; also apply the same replacement for the other affected list
endpoints that currently reference OpenConsumerInfoDTO so tokens are not leaked
at scale.
---
Minor comments:
In `@apollo-openapi.yaml`:
- Around line 6857-6860: The rateLimit integer schema currently allows negative
values even though 0 means unlimited; update the rateLimit schema (the property
named "rateLimit") to constrain values to non-negative by adding a minimum: 0
(or minimum: 0 and exclusiveMinimum: false) so negatives are rejected, and apply
the same change to the second occurrence of the rateLimit schema referenced in
the comment.
In `@java-client/docs/UserManagementApi.md`:
- Around line 291-297: Add a blank line before and after the "HTTP response
details" table in UserManagementApi.md (the table under the "### HTTP response
details" heading) so the Markdown table is separated by empty lines and
satisfies MD058; ensure there is one empty line between the heading and the
table and one empty line after the table.
- Around line 235-291: The new getUserByUserId section uses H3 (###) directly
under an H1, triggering MD001; update the heading levels in the getUserByUserId
block (e.g., change "### Example", "### Parameters", "### Return type", "###
Authorization", "### HTTP request headers", "### HTTP response details") to be
one level higher (use "##" instead of "###") so subsections increment correctly
under the top-level H1; locate headings around the getUserByUserId examples and
adjust them accordingly.
In
`@java-client/src/main/java/org/openapitools/client/model/OpenConsumerInfoDTO.java`:
- Around line 419-427: In validateJsonObject, after checking jsonObj == null and
handling required fields with OpenConsumerInfoDTO.openapiRequiredFields, return
immediately when jsonObj is null (and no required fields) to avoid dereferencing
jsonObj; that is, ensure the method exits before reaching the line that computes
Set<Entry<String, JsonElement>> entries = jsonObj.entrySet(); so subsequent code
only runs when jsonObj is non-null.
In
`@java-client/src/test/java/org/openapitools/client/model/OpenConsumerCreateRequestDTOTest.java`:
- Around line 34-109: Replace the TODOs with real assertions: instantiate
OpenConsumerCreateRequestDTO, set example values for each field (appId,
allowCreateApplication, allowManageUsers, name, orgId, orgName, ownerName,
rateLimitEnabled, rateLimit) using the DTO's setters, then assert the
corresponding getters return the same values (use Assert.assertEquals /
assertTrue as appropriate) inside testOpenConsumerCreateRequestDTO and/or in
each specific test method (appIdTest, allowCreateApplicationTest,
allowManageUsersTest, nameTest, orgIdTest, orgNameTest, ownerNameTest,
rateLimitEnabledTest, rateLimitTest); optionally add simple assertions for
toString()/equals()/hashCode() on the populated instance to increase coverage.
In
`@java-client/src/test/java/org/openapitools/client/model/OpenConsumerInfoDTOTest.java`:
- Around line 34-125: Replace the TODO stubs in OpenConsumerInfoDTOTest by
building a real OpenConsumerInfoDTO instance in testOpenConsumerInfoDTO and in
each property test (appIdTest, nameTest, orgIdTest, orgNameTest, ownerNameTest,
ownerEmailTest, consumerIdTest, tokenTest, allowCreateApplicationTest,
allowManageUsersTest, rateLimitTest) set the corresponding field (via
constructor or setters) and assert expected behavior using JUnit assertions
(e.g., assertEquals for getter values, assertNotNull where appropriate); also
add a simple equality/hashCode/toString check in testOpenConsumerInfoDTO to
validate model contract.
In `@python/apollo_openapi/paths/openapi_v1_consumers/get.pyi`:
- Line 79: The _arg type annotation for the list-schema constructor uses a
fixed-length tuple form for OpenConsumerInfoDTO; update the annotation for _arg
(the union branch that currently has typing.Tuple['OpenConsumerInfoDTO']) to the
variable-length tuple form (use Tuple with an ellipsis) so it accepts
arbitrary-length tuples/lists of OpenConsumerInfoDTO instead of only a
single-element tuple.
In `@python/docs/apis/tags/PortalManagementApi.md`:
- Around line 624-627: The table rows in the typed DTO sections (e.g., the row
referencing OpenConsumerCreateRequestDTO) have fewer cells than the header (Type
| Description | Notes); update each malformed row so it has three pipe-separated
cells — for example "
[**OpenConsumerCreateRequestDTO**](../../models/OpenConsumerCreateRequestDTO.md)
| | " or provide text for Description/Notes — ensuring every data row matches
the header column count in the PortalManagementApi.md typed DTO tables.
- Line 3084: The table row containing the three links to OpenConsumerInfoDTO
still has the unresolved token "{{complexTypePrefix}}" and is missing the fourth
column; update the three link targets in the row (the occurrences of
"{{complexTypePrefix}}OpenConsumerInfoDTO.md") to the correct target (e.g.,
"OpenConsumerInfoDTO.md" or the actual complexTypePrefix value used elsewhere)
and restore the fourth column (add a meaningful cell or a placeholder like "-"
or "N/A") so the row renders with four columns; locate the row by the link text
"OpenConsumerInfoDTO" to apply the change.
In `@python/docs/apis/tags/UserManagementApi.md`:
- Around line 526-528: The in-page response links for get_user_by_user_id are
using invalid fragment targets (e.g. "`#get_user_by_user_id.ApiResponseFor200`",
"`#get_user_by_user_id.ApiResponseFor400`",
"`#get_user_by_user_id.ApiResponseFor403`"); open the markdown, locate the actual
headings for the ApiResponseFor200/ApiResponseFor400/ApiResponseFor403 sections
under get_user_by_user_id, copy the exact rendered anchor IDs for those headings
and replace the broken fragments with those exact anchors so the links resolve
correctly (update the three link targets that reference
ApiResponseFor200/400/403).
In `@python/docs/models/OpenConsumerCreateRequestDTO.md`:
- Around line 4-6: The table row under "Model Type Info" has only three cells
causing a markdown table shape error; update the row that currently starts with
"dict, frozendict.frozendict," so it has four pipe-separated cells to match the
header (Input Type | Accessed Type | Description | Notes), e.g., add an extra
trailing " | " to create the missing empty cell(s) or fill them with the
appropriate Description/Notes text for OpenConsumerCreateRequestDTO.
In `@python/docs/models/OpenConsumerInfoDTO.md`:
- Around line 4-6: The table row under the "Model Type Info" header in
OpenConsumerInfoDTO.md has only three pipe-separated columns, causing markdown
errors; update the offending row (the line starting with "dict,
frozendict.frozendict, | frozendict.frozendict, |") to include the missing
fourth column so it has four columns matching the header "Input Type | Accessed
Type | Description | Notes" (you can add an empty value or appropriate note in
the fourth column).
In `@rust/docs/OpenConsumerCreateRequestDto.md`:
- Around line 8-9: The Notes column uses reference-style bracket text like
"[optional][default to false]" which creates undefined Markdown links; update
occurrences for the fields allow_create_application and allow_manage_users (and
the similar occurrences around lines for the other two fields) to a
non-reference form such as "(optional, default to false)" or "optional —
default: false" so the text isn't parsed as a reference link; ensure all four
instances are changed consistently.
In `@rust/docs/OpenConsumerInfoDto.md`:
- Around line 15-17: The property notes in OpenConsumerInfoDto.md use bracketed
tokens like "[optional][default to false]" which are parsed as reference links;
update the three property lines for allow_create_application,
allow_manage_users, and rate_limit to use inline plain text or parentheses (e.g.
"(optional, default: false)" and "(optional, default: 0)") instead of bracketed
reference syntax so the docs render correctly.
In
`@spring-boot2/src/main/java/com/apollo/openapi/server/api/UserManagementApiDelegate.java`:
- Line 18: The class/interface Javadoc for UserManagementApiDelegate contains a
malformed link "{`@link` UserManagementApiController}}" with an extra closing
brace; edit the Javadoc comment for UserManagementApiDelegate and change the
link to "{`@link` UserManagementApiController}" (remove the extra "}") so the
{`@link` UserManagementApiController} reference resolves correctly.
In `@spring-boot2/src/main/resources/openapi.yaml`:
- Around line 5966-5983: The getUserByUserId OpenAPI operation is missing the
401 unauthenticated response; update the OpenAPI entry for GET
/openapi/v1/users/{userId} (the operation that currently lists "200", "400",
"403") to include a "401" response using the same ExceptionResponse schema as
the other user endpoints so unauthenticated failure is documented consistently
with the GET /openapi/v1/users operation.
In `@tests/test_user_management_contract.py`:
- Around line 19-20: The _load_spec method uses (self.repo_root /
spec_file).read_text() which relies on the system default encoding and can raise
UnicodeDecodeError for non-ASCII YAML; change the call to
read_text(encoding="utf-8") so yaml.safe_load always gets UTF‑8 decoded text
(update the _load_spec function accordingly).
🪄 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: defaults
Review profile: CHILL
Plan: Pro
Run ID: c0b7605d-ac68-4099-b8f8-986d8957a227
📒 Files selected for processing (96)
CHANGELOG.mdapollo-openapi.yamlgenerate.shjava-client/.openapi-generator/FILESjava-client/README.mdjava-client/api/openapi.yamljava-client/build.gradlejava-client/build.sbtjava-client/docs/OpenConsumerCreateRequestDTO.mdjava-client/docs/OpenConsumerInfoDTO.mdjava-client/docs/PortalManagementApi.mdjava-client/docs/UserManagementApi.mdjava-client/pom.xmljava-client/src/main/java/org/openapitools/client/ApiClient.javajava-client/src/main/java/org/openapitools/client/Configuration.javajava-client/src/main/java/org/openapitools/client/JSON.javajava-client/src/main/java/org/openapitools/client/api/PortalManagementApi.javajava-client/src/main/java/org/openapitools/client/api/UserManagementApi.javajava-client/src/main/java/org/openapitools/client/model/OpenConsumerCreateRequestDTO.javajava-client/src/main/java/org/openapitools/client/model/OpenConsumerInfoDTO.javajava-client/src/test/java/org/openapitools/client/api/PortalManagementApiTest.javajava-client/src/test/java/org/openapitools/client/api/UserManagementApiTest.javajava-client/src/test/java/org/openapitools/client/model/OpenConsumerCreateRequestDTOTest.javajava-client/src/test/java/org/openapitools/client/model/OpenConsumerInfoDTOTest.javapython/.openapi-generator/FILESpython/README.mdpython/apollo_openapi/__init__.pypython/apollo_openapi/api_client.pypython/apollo_openapi/apis/path_to_api.pypython/apollo_openapi/apis/paths/openapi_v1_users_user_id.pypython/apollo_openapi/apis/tag_to_api.pypython/apollo_openapi/apis/tags/__init__.pypython/apollo_openapi/apis/tags/user_management_api.pypython/apollo_openapi/configuration.pypython/apollo_openapi/model/open_consumer_create_request_dto.pypython/apollo_openapi/model/open_consumer_create_request_dto.pyipython/apollo_openapi/model/open_consumer_info_dto.pypython/apollo_openapi/model/open_consumer_info_dto.pyipython/apollo_openapi/models/__init__.pypython/apollo_openapi/paths/__init__.pypython/apollo_openapi/paths/openapi_v1_consumers/get.pypython/apollo_openapi/paths/openapi_v1_consumers/get.pyipython/apollo_openapi/paths/openapi_v1_consumers/post.pypython/apollo_openapi/paths/openapi_v1_consumers/post.pyipython/apollo_openapi/paths/openapi_v1_users/get.pypython/apollo_openapi/paths/openapi_v1_users/get.pyipython/apollo_openapi/paths/openapi_v1_users/post.pypython/apollo_openapi/paths/openapi_v1_users/post.pyipython/apollo_openapi/paths/openapi_v1_users_enabled/put.pypython/apollo_openapi/paths/openapi_v1_users_enabled/put.pyipython/apollo_openapi/paths/openapi_v1_users_user_id/__init__.pypython/apollo_openapi/paths/openapi_v1_users_user_id/get.pypython/apollo_openapi/paths/openapi_v1_users_user_id/get.pyipython/docs/apis/tags/PortalManagementApi.mdpython/docs/apis/tags/UserManagementApi.mdpython/docs/models/OpenConsumerCreateRequestDTO.mdpython/docs/models/OpenConsumerInfoDTO.mdpython/setup.pypython/test/test_models/test_open_consumer_create_request_dto.pypython/test/test_models/test_open_consumer_info_dto.pypython/test/test_paths/test_openapi_v1_users/test_get.pypython/test/test_paths/test_openapi_v1_users/test_post.pypython/test/test_paths/test_openapi_v1_users_enabled/test_put.pypython/test/test_paths/test_openapi_v1_users_user_id/__init__.pypython/test/test_paths/test_openapi_v1_users_user_id/test_get.pyrust/.openapi-generator/FILESrust/Cargo.tomlrust/README.mdrust/docs/OpenConsumerCreateRequestDto.mdrust/docs/OpenConsumerInfoDto.mdrust/src/apis/configuration.rsrust/src/models/mod.rsrust/src/models/open_consumer_create_request_dto.rsrust/src/models/open_consumer_info_dto.rsspring-boot2/.openapi-generator/FILESspring-boot2/pom.xmlspring-boot2/src/main/java/com/apollo/openapi/server/api/PortalManagementApi.javaspring-boot2/src/main/java/com/apollo/openapi/server/api/PortalManagementApiController.javaspring-boot2/src/main/java/com/apollo/openapi/server/api/PortalManagementApiDelegate.javaspring-boot2/src/main/java/com/apollo/openapi/server/api/UserManagementApi.javaspring-boot2/src/main/java/com/apollo/openapi/server/api/UserManagementApiController.javaspring-boot2/src/main/java/com/apollo/openapi/server/api/UserManagementApiDelegate.javaspring-boot2/src/main/java/com/apollo/openapi/server/config/SpringDocConfiguration.javaspring-boot2/src/main/java/com/apollo/openapi/server/model/OpenConsumerCreateRequestDTO.javaspring-boot2/src/main/java/com/apollo/openapi/server/model/OpenConsumerInfoDTO.javaspring-boot2/src/main/resources/openapi.yamltests/test_user_management_contract.pytypescript/.openapi-generator/FILEStypescript/README.mdtypescript/package.jsontypescript/src/apis/PortalManagementApi.tstypescript/src/apis/UserManagementApi.tstypescript/src/apis/index.tstypescript/src/models/OpenConsumerCreateRequestDTO.tstypescript/src/models/OpenConsumerInfoDTO.tstypescript/src/models/index.ts
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 0a6ac879a1
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| application/json: | ||
| schema: | ||
| type: object | ||
| $ref: '#/components/schemas/OpenConsumerInfoDTO' |
There was a problem hiding this comment.
Use a token schema for the token lookup
For /openapi/v1/consumer-tokens/by-appId, the Apollo Portal controller's getConsumerTokenByAppId returns a ConsumerToken (token, consumerId, rateLimit, expires, audit fields), not a consumer detail object. With this $ref, generated clients deserialize the token endpoint as OpenConsumerInfoDTO, so callers lose fields such as expires and see unrelated app/owner fields instead; please model this response as a token DTO (or point the consumer-detail schema at the separate consumer-info endpoint).
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Thanks, this is valid. I fixed it in follow-up PR #31 by introducing OpenConsumerTokenDTO for /openapi/v1/consumer-tokens/by-appId and regenerating the SDK/server artifacts. The Apollo implementation is also being aligned to call consumerService.getConsumerTokenByAppId(appId) and return the token DTO, matching the legacy WebAPI behavior.
| rateLimit: | ||
| type: integer | ||
| description: 限流QPS,0表示不限流 | ||
| minimum: 0 | ||
| default: 0 |
There was a problem hiding this comment.
Require positive QPS when rate limiting is enabled
When callers create a consumer with rateLimitEnabled=true, Apollo's ConsumerController.create rejects rateLimit <= 0 before saving the token, but this request schema advertises 0 as valid and as the default for the same property. Generated clients and docs therefore accept a payload that fails whenever a caller enables rate limiting without also overriding the default; please express the enabled case as requiring a positive QPS, or avoid advertising 0 as the default on that path.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Thanks, fixed in #31. OpenConsumerCreateRequestDTO.rateLimit no longer advertises default: 0, and the schema description now states that rateLimitEnabled=true requires a positive QPS while 0 means unlimited only when rate limiting is disabled. I avoided a oneOf shape here because it changes generated request DTO types in a way that would unnecessarily break the Apollo portal implementation.
| OpenConsumerCreateRequestDTO: | ||
| type: object | ||
| properties: |
There was a problem hiding this comment.
Require the consumer fields the server validates
For POST /openapi/v1/consumers, Apollo rejects blank appId, name, ownerName, and orgId before creating the consumer, but this new typed request schema has no required list, so all of those fields become optional in generated clients and docs. Callers can now build a supposedly valid OpenConsumerCreateRequestDTO that only fails at runtime with 400; please mark the server-required fields as required in the schema.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Thanks, fixed in #31. OpenConsumerCreateRequestDTO now marks the fields the server validates as required: appId, name, orgId, and ownerName. I intentionally did not mark orgName required because the Apollo controller does not reject it when blank.
| allowManageUsers: | ||
| type: boolean | ||
| description: 是否允许该Consumer Token管理用户 | ||
| default: false |
There was a problem hiding this comment.
Remove unsupported manage-users grants
When a client creates a consumer with allowManageUsers=true, this contract implies the token will be granted access to the user-management endpoints, but there is no corresponding manage-users role assignment path in the spec and Apollo's consumer creation flow only handles the existing create-application grant. The flag will therefore be ignored or omitted by current servers while generated clients/docs tell callers it enables user management; please either wire the grant end-to-end or leave this field out until it is supported.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Thanks, this was a valid concern for the old server state. I am keeping allowManageUsers in the contract because the paired Apollo implementation wires it end to end: consumer creation now calls assignManageUsersRoleToConsumer(...), and consumer tokens with the new ManageUsers permission can access the user-management endpoints. This is covered by the follow-up Apollo work rather than by removing the field from the OpenAPI schema.
Summary
Tests
Notes
Summary by CodeRabbit
Release Notes v0.3.6
New Features
Documentation