Support for component health (components service)#62
Merged
agustingroh merged 9 commits intomainfrom Feb 24, 2026
Merged
Conversation
|
Warning Rate limit exceeded
⌛ How to resolve this issue?After the wait time has elapsed, 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 have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ⛔ Files ignored due to path filters (3)
📒 Files selected for processing (3)
📝 WalkthroughWalkthroughAdded two RPCs and HTTP endpoints to retrieve single-component and bulk component status; introduced new protobuf messages ( Changes
Sequence Diagram(s)sequenceDiagram
participant Client
participant APIGW as API Gateway
participant Components as Components Service
participant Indexer as Indexing/Status Store
Client->>APIGW: GET /v2/components/status/component?purl=...
APIGW->>Components: GetComponentStatus(request)
Components->>Indexer: Query component & version status by purl
Indexer-->>Components: component_status + version_status
Components-->>APIGW: ComponentStatusResponse
APIGW-->>Client: 200 OK + JSON
rect rgba(0,128,0,0.5)
note over Components,Indexer: POST /v2/components/status/components handles batched requests and returns ComponentsStatusResponse
end
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 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: 7
🤖 Fix all issues with AI agents
In `@protobuf/scanoss/api/components/v2/scanoss-components.proto`:
- Around line 205-207: Fix the typo in the comment above the fields by changing
"seatching" to "searching" and make the ErrorCode reference fully qualified and
consistent with the rest of the file by replacing the type on the error_code
field with scanoss.api.common.v2.ErrorCode; update the comment that references
the status of the component version lookup and the error_code field declaration
(error_message and error_code) accordingly to use the corrected wording and
fully qualified type name.
- Around line 219-221: Fix the typo in the comment for the component status by
changing "seatching" to "searching" and make the error_code field's type
reference consistent with VersionStatus by replacing common.v2.ErrorCode with
scanoss.api.common.v2.ErrorCode; update the comment text near the optional
string error_message = 5 and change the type of optional common.v2.ErrorCode
error_code = 6 to optional scanoss.api.common.v2.ErrorCode error_code = 6
(fields: error_message, error_code).
- Around line 196-208: The VersionStatus message is missing a version field
referenced by the openapiv2_schema and swagger example; add a new string field
named version to the VersionStatus proto (e.g., `string version = 7;`) so it
carries the version identifier, and then update the corresponding
generated/openapi swagger type (ComponentStatusResponseVersionStatus) to include
a version property in its schema/example to match the proto change.
- Around line 234-246: Update the ComponentsStatusResponse message declaration:
change the top comment text from "Component Statistics response data (JSON
payload)" to "Component Status response data (JSON payload)"; remove the
duplicated semicolon after the field declaration for repeated
ComponentStatusResponse component_status = 1 [json_name = "components"]; and
eliminate the extra blank lines around the message and option block to restore
consistent spacing and readability (refer to the message name
ComponentsStatusResponse and the field component_status to locate the changes).
In `@protobuf/scanoss/api/components/v2/scanoss-components.swagger.json`:
- Around line 384-411: The ComponentStatusResponseVersionStatus schema is
missing the version property referenced by examples; add a "version" property
(type: string) to the ComponentStatusResponseVersionStatus definition with a
descriptive title like "Version string for this component version", so the JSON
schema matches the proto's VersionStatus message once the proto field is added;
update ComponentStatusResponseVersionStatus's properties to include "version" to
align examples and downstream consumers.
- Around line 693-696: The generated Swagger title for component_status contains
a leading "/" because the proto comment used a triple-slash doc comment (///);
open the proto definition for the ComponentStatusResponseComponentStatus message
and replace the leading triple-slash comment with a normal double-slash comment
(change "/// Information about the current development status of the component"
to "// Information about the current development status of the component"), then
re-run the protobuf->swagger generation so the "title" for component_status no
longer starts with a slash.
- Around line 772-808: The swagger object v2ComponentsStatusResponse has two
issues: the title should be "Component Status response data" (update the
proto/title and regenerate the swagger or edit the swagger title) and the
property key is wrong — the spec lists "component_status" but the proto uses
json_name="components" (and the example uses "components"), so change the
property name in v2ComponentsStatusResponse from "component_status" to
"components" (ensure its items still reference v2ComponentStatusResponse) or
adjust protoc-gen-openapiv2 config to honor json_name and then regenerate the
swagger so the wire-format matches the proto.
🧹 Nitpick comments (1)
protobuf/scanoss/api/components/v2/scanoss-components.swagger.json (1)
827-837: Newv2ErrorCodeenum looks reasonable.The four error codes (
INVALID_PURL,COMPONENT_NOT_FOUND,NO_INFO,INVALID_SEMVER) cover the expected failure modes. Note thatdefault: "INVALID_PURL"is auto-generated from proto3's first-enum-value-is-default behavior — consider whether the first value should be anUNSPECIFIEDsentinel (as done withv2StatusCode) to avoid accidentally defaulting to a meaningful error code.
Comment on lines
219
to
221
| // States if something went wrong while seatching the component on DB | ||
| optional string error_message = 5 [json_name = "error_message"]; | ||
| optional common.v2.ErrorCode error_code = 6 [json_name = "error_code"]; |
There was a problem hiding this comment.
Same typo and inconsistent type reference as in VersionStatus.
Line 219: "seatching" → "searching". Line 221: prefer scanoss.api.common.v2.ErrorCode for consistency.
,
Proposed fix
- // States if something went wrong while seatching the component on DB
+ // States if something went wrong while searching the component on DB
optional string error_message = 5 [json_name = "error_message"];
- optional common.v2.ErrorCode error_code = 6 [json_name = "error_code"];
+ optional scanoss.api.common.v2.ErrorCode error_code = 6 [json_name = "error_code"];📝 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.
Suggested change
| // States if something went wrong while seatching the component on DB | |
| optional string error_message = 5 [json_name = "error_message"]; | |
| optional common.v2.ErrorCode error_code = 6 [json_name = "error_code"]; | |
| // States if something went wrong while searching the component on DB | |
| optional string error_message = 5 [json_name = "error_message"]; | |
| optional scanoss.api.common.v2.ErrorCode error_code = 6 [json_name = "error_code"]; |
🤖 Prompt for AI Agents
In `@protobuf/scanoss/api/components/v2/scanoss-components.proto` around lines 219
- 221, Fix the typo in the comment for the component status by changing
"seatching" to "searching" and make the error_code field's type reference
consistent with VersionStatus by replacing common.v2.ErrorCode with
scanoss.api.common.v2.ErrorCode; update the comment text near the optional
string error_message = 5 and change the type of optional common.v2.ErrorCode
error_code = 6 to optional scanoss.api.common.v2.ErrorCode error_code = 6
(fields: error_message, error_code).
Comment on lines
234
to
246
| /* | ||
| * Component Statistics response data (JSON payload) | ||
| */ | ||
| message ComponentsStatusResponse { | ||
| option (grpc.gateway.protoc_gen_openapiv2.options.openapiv2_schema) = { | ||
| json_schema: { | ||
| example: "{\"components\":[ { \"purl\": \"pkg:npm/strive-molu-axios\",\"name\":\"strive-molu-axios\",\"version_status\": { \"version\": \"0.0.1-beta.1\", \"status\": \"deleted\", \"indexed_date\": \"2024-06-21\", \"check_date\": \"2026-02-01\" }, \"component_status\": { \"status\": \"active\",\"first_indexed_date\": \"2022-03-01\", \"last_indexed_date\": \"2026-02-15\" } }]}" ; | ||
| } | ||
| }; | ||
|
|
||
|
|
||
| // Component status | ||
| repeated ComponentStatusResponse component_status = 1 [json_name = "components"];; |
There was a problem hiding this comment.
Copy-paste issues: wrong doc comment, double semicolon, and extra blank lines.
- Line 235: Comment says "Component Statistics response data" but this is the Status response. Should be "Component Status response data".
- Line 246: Double semicolon
;;— while protoc may tolerate this, it's unintended. - Lines 230–233, 243–244: Excessive blank lines reduce readability.
Proposed fix
-
-
-
-
/*
- * Component Statistics response data (JSON payload)
+ * Component Status response data (JSON payload)
*/
message ComponentsStatusResponse {
option (grpc.gateway.protoc_gen_openapiv2.options.openapiv2_schema) = {
json_schema: {
example: "{\"components\":[ { \"purl\": \"pkg:npm/strive-molu-axios\",\"name\":\"strive-molu-axios\",\"version_status\": { \"version\": \"0.0.1-beta.1\", \"status\": \"deleted\", \"indexed_date\": \"2024-06-21\", \"check_date\": \"2026-02-01\" }, \"component_status\": { \"status\": \"active\",\"first_indexed_date\": \"2022-03-01\", \"last_indexed_date\": \"2026-02-15\" } }]}" ;
}
- };
-
-
+ };
// Component status
- repeated ComponentStatusResponse component_status = 1 [json_name = "components"];;
+ repeated ComponentStatusResponse component_status = 1 [json_name = "components"];
// Response status
- scanoss.api.common.v2.StatusResponse status = 2;
+ scanoss.api.common.v2.StatusResponse status = 2;
}🤖 Prompt for AI Agents
In `@protobuf/scanoss/api/components/v2/scanoss-components.proto` around lines 234
- 246, Update the ComponentsStatusResponse message declaration: change the top
comment text from "Component Statistics response data (JSON payload)" to
"Component Status response data (JSON payload)"; remove the duplicated semicolon
after the field declaration for repeated ComponentStatusResponse
component_status = 1 [json_name = "components"]; and eliminate the extra blank
lines around the message and option block to restore consistent spacing and
readability (refer to the message name ComponentsStatusResponse and the field
component_status to locate the changes).
There was a problem hiding this comment.
🧹 Nitpick comments (2)
protobuf/scanoss/api/components/v2/scanoss-components.proto (2)
222-222: Triple-slash///comment — use//for consistency.Line 222 uses
///while the rest of the file uses//for single-line comments. While protobuf accepts both, this is inconsistent.Proposed fix
- /// Information about the current development status of the component + // Information about the current development status of the component
182-187: Inconsistent indentation in OpenAPI schema option blocks.Lines 183–187 use mixed indentation (5-space indent for the
option, 4-space forjson_schema), and line 234 has significant trailing whitespace. The existing messages in the file (e.g., lines 129–133, 163–167) use a consistent 2-space indent. Consider aligning the new blocks to match.Also applies to: 230-234
eeisegn
requested changes
Feb 16, 2026
There was a problem hiding this comment.
🧹 Nitpick comments (2)
protobuf/scanoss/api/components/v2/scanoss-components.proto (2)
204-221: Minor comment/formatting issues inComponentStatusblock.
- Line 214: Comment says "searching for the version of this component" but
ComponentStatusis version-agnostic — should be "searching for this component in the DB".- Line 215: Double space between
optionalandstring.- Line 220: Triple-slash
///— proto3 uses//for single-line comments. While///compiles, it's non-idiomatic.Proposed fix
- // States if something went wrong while searching for the version of this component in the DB - optional string error_message = 5 [json_name = "error_message"]; + // States if something went wrong while searching for this component in the DB + optional string error_message = 5 [json_name = "error_message"]; optional common.v2.ErrorCode error_code = 6 [json_name = "error_code"]; } - /// Information about the current development status of the component + // Information about the current development status of the component
177-237: Inconsistent indentation across the new messages.The existing messages in this file use 2-space indentation (e.g.,
ComponentsStatisticResponseat Line 160). The new blocks mix 3-space, 5-space, and other alignments (Lines 181, 228, 234). There's also trailing whitespace on several lines (185, 192, 206, 232, 236). A quick reformatting pass would bring this in line with the rest of the file.
eeisegn
requested changes
Feb 16, 2026
Contributor
eeisegn
left a comment
eeisegn
left a comment
There was a problem hiding this comment.
the version and requirement field appear to be missing from the status response?
please look at the latest vulnerability definition. it has examples of requirement and version together.
Suggested Changelog EntriesBased on the changes in this PR, here are the suggested entries for the ## [Unreleased]
### Added
- Added gRPC `GetComponentStatus` and REST endpoint GET `/v2/components/status/component` for retrieving lifecycle status of a single component
- Added gRPC `GetComponentsStatus` and REST endpoint POST `/v2/components/status/components` for retrieving lifecycle status of multiple components in bulk
- Added `ComponentStatusResponse` message with `purl`, `name`, and `requirement` fields, plus nested `VersionStatus` and `ComponentStatus` messages for version-level and component-level lifecycle information
- Added `repository_status` field to `VersionStatus` and `ComponentStatus` messages to expose the raw status reported by the package registry
- Added `error_message` and `error_code` fields to `VersionStatus` and `ComponentStatus` messages for enhanced error handling in component status responses
- Added `ComponentsStatusResponse` message for bulk component status responses |
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@protobuf/scanoss/api/components/v2/scanoss-components.swagger.json`:
- Around line 781-800: The example for v2ComponentsStatusResponse is missing the
top-level "status" property declared in the schema; update the example object so
it includes a "status" field that matches the v2StatusResponse structure (e.g.,
status code/message or whatever v2StatusResponse requires) alongside the
existing "components" array so the example reflects the full
v2ComponentsStatusResponse shape.
- Around line 665-706: v2ComponentStatusResponse currently lacks the common
top-level "status" envelope used by other responses; update the schema for
v2ComponentStatusResponse to include a top-level "status" property referencing
"#/definitions/v2StatusResponse" (matching v2CompSearchResponse,
v2CompVersionResponse, v2ComponentsStatisticResponse,
v2ComponentsStatusResponse) and update the example object under
v2ComponentStatusResponse to include a corresponding "status" example entry, or
alternatively explicitly document in the v2ComponentStatusResponse description
that errors are communicated only via per-field error_code/error_message if you
intend to keep it without the "status" envelope.
- Around line 835-845: The v2ErrorCode enum must include a zero-value sentinel
so unset/“no error” doesn't serialize as INVALID_PURL; update the proto to add
an initial UNSPECIFIED (or UNDEFINED) enum value as the first member of
v2ErrorCode (mirroring v2StatusCode’s zero-value pattern), move existing values
(INVALID_PURL, COMPONENT_NOT_FOUND, NO_INFO, INVALID_SEMVER) after it, then
regenerate the swagger/json so
protobuf/scanoss/api/components/v2/scanoss-components.swagger.json reflects the
new ordering; ensure any code that switches on v2ErrorCode treats UNSPECIFIED as
the default/no-error case.
---
Duplicate comments:
In `@protobuf/scanoss/api/components/v2/scanoss-components.swagger.json`:
- Around line 700-703: The title for component_status is incorrectly including a
leading slash because the proto comment used triple-slash "///" (which becomes a
proto comment artifact) instead of a normal double-slash; open the proto that
defines ComponentStatusResponseComponentStatus (the field/component for
component_status) and change the `///` comment to `//` (or remove the leading
slash in the comment), then regenerate the OpenAPI/Swagger JSON so the title
becomes "Information about the current development status of the component".
- Line 815: The JSON schema title is incorrect: update the title value
"Component Statistics response data (JSON payload)" to "Component Status
response data (JSON payload)" in the OpenAPI/Swagger definition (the title field
inside the scanoss components v2 schema) so the schema name correctly reflects
Component Status responses.
- Around line 385-413: The schema ComponentStatusResponseVersionStatus is
missing the version property that appears in examples (e.g., "version":
"0.0.1-beta.1"); update the ComponentStatusResponseVersionStatus definition to
add a "version" property of type string (with an appropriate title like "Version
string for this component") so consumers of the spec can parse and document the
version field; ensure this property is added alongside existing properties such
as "status", "repository_status", "indexed_date", "check_date", "error_message",
and "error_code".
Comment on lines
+665
to
+706
| "v2ComponentStatusResponse": { | ||
| "type": "object", | ||
| "example": { | ||
| "purl": "pkg:npm/strive-molu-axios", | ||
| "name": "strive-molu-axios", | ||
| "requirement": "^0.0.1", | ||
| "version_status": { | ||
| "version": "0.0.1-beta.1", | ||
| "status": "deleted", | ||
| "indexed_date": "2024-06-21", | ||
| "check_date": "2026-02-01" | ||
| }, | ||
| "component_status": { | ||
| "status": "active", | ||
| "first_indexed_date": "2022-03-01", | ||
| "last_indexed_date": "2026-02-15" | ||
| } | ||
| }, | ||
| "properties": { | ||
| "purl": { | ||
| "type": "string", | ||
| "title": "Purl requested" | ||
| }, | ||
| "name": { | ||
| "type": "string", | ||
| "title": "Name of the component" | ||
| }, | ||
| "requirement": { | ||
| "type": "string", | ||
| "description": "Requirement that should be met on the response." | ||
| }, | ||
| "version_status": { | ||
| "$ref": "#/definitions/ComponentStatusResponseVersionStatus", | ||
| "title": "Information about the requested version. If no requirement is described, the latest version of the component is responded" | ||
| }, | ||
| "component_status": { | ||
| "$ref": "#/definitions/ComponentStatusResponseComponentStatus", | ||
| "title": "/ Information about the current development status of the component" | ||
| } | ||
| }, | ||
| "title": "Component lifecycle status" | ||
| }, |
There was a problem hiding this comment.
v2ComponentStatusResponse is the only top-level response type without a status field.
Every other response schema in this file (v2CompSearchResponse, v2CompVersionResponse, v2ComponentsStatisticResponse, v2ComponentsStatusResponse) carries a top-level "status": { "$ref": "#/definitions/v2StatusResponse" } envelope. The single-component GET response omits it, forcing consumers to diverge their error-handling logic for this endpoint. If the intent is that errors are expressed entirely through per-field error_code/error_message, document that explicitly; otherwise add the field for consistency.
💡 Proposed addition
"version_status": { ... },
"component_status": { ... }
+ },
+ "status": {
+ "$ref": "#/definitions/v2StatusResponse",
+ "title": "Response status"
}🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@protobuf/scanoss/api/components/v2/scanoss-components.swagger.json` around
lines 665 - 706, v2ComponentStatusResponse currently lacks the common top-level
"status" envelope used by other responses; update the schema for
v2ComponentStatusResponse to include a top-level "status" property referencing
"#/definitions/v2StatusResponse" (matching v2CompSearchResponse,
v2CompVersionResponse, v2ComponentsStatisticResponse,
v2ComponentsStatusResponse) and update the example object under
v2ComponentStatusResponse to include a corresponding "status" example entry, or
alternatively explicitly document in the v2ComponentStatusResponse description
that errors are communicated only via per-field error_code/error_message if you
intend to keep it without the "status" envelope.
Comment on lines
+781
to
+800
| "example": { | ||
| "components": [ | ||
| { | ||
| "purl": "pkg:npm/strive-molu-axios", | ||
| "name": "strive-molu-axios", | ||
| "requirement": "^0.0.1", | ||
| "version_status": { | ||
| "version": "0.0.1-beta.1", | ||
| "status": "deleted", | ||
| "indexed_date": "2024-06-21", | ||
| "check_date": "2026-02-01" | ||
| }, | ||
| "component_status": { | ||
| "status": "active", | ||
| "first_indexed_date": "2022-03-01", | ||
| "last_indexed_date": "2026-02-15" | ||
| } | ||
| } | ||
| ] | ||
| }, |
There was a problem hiding this comment.
Example for v2ComponentsStatusResponse omits the status property defined in the schema.
The schema at lines 810–813 includes "status": { "$ref": "#/definitions/v2StatusResponse" }, but the example only shows the components array. Incomplete examples mislead consumers about the response shape.
💡 Suggested addition to the example
}
]
+ },
+ "status": {
+ "status": "SUCCESS",
+ "message": "Component status successfully retrieved"
}
},📝 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.
Suggested change
| "example": { | |
| "components": [ | |
| { | |
| "purl": "pkg:npm/strive-molu-axios", | |
| "name": "strive-molu-axios", | |
| "requirement": "^0.0.1", | |
| "version_status": { | |
| "version": "0.0.1-beta.1", | |
| "status": "deleted", | |
| "indexed_date": "2024-06-21", | |
| "check_date": "2026-02-01" | |
| }, | |
| "component_status": { | |
| "status": "active", | |
| "first_indexed_date": "2022-03-01", | |
| "last_indexed_date": "2026-02-15" | |
| } | |
| } | |
| ] | |
| }, | |
| "example": { | |
| "components": [ | |
| { | |
| "purl": "pkg:npm/strive-molu-axios", | |
| "name": "strive-molu-axios", | |
| "requirement": "^0.0.1", | |
| "version_status": { | |
| "version": "0.0.1-beta.1", | |
| "status": "deleted", | |
| "indexed_date": "2024-06-21", | |
| "check_date": "2026-02-01" | |
| }, | |
| "component_status": { | |
| "status": "active", | |
| "first_indexed_date": "2022-03-01", | |
| "last_indexed_date": "2026-02-15" | |
| } | |
| } | |
| ], | |
| "status": { | |
| "status": "SUCCESS", | |
| "message": "Component status successfully retrieved" | |
| } | |
| }, |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@protobuf/scanoss/api/components/v2/scanoss-components.swagger.json` around
lines 781 - 800, The example for v2ComponentsStatusResponse is missing the
top-level "status" property declared in the schema; update the example object so
it includes a "status" field that matches the v2StatusResponse structure (e.g.,
status code/message or whatever v2StatusResponse requires) alongside the
existing "components" array so the example reflects the full
v2ComponentsStatusResponse shape.
Suggested Changelog EntriesBased on the changes in this PR, here are the suggested entries for the ## [Unreleased]
### Added
- Added gRPC `GetComponentStatus` and REST endpoint GET `/v2/components/status/component` for retrieving lifecycle status of a single component
- Added gRPC `GetComponentsStatus` and REST endpoint POST `/v2/components/status/components` for retrieving lifecycle status of multiple components in a single request
- Added `ComponentStatusResponse` message with `VersionStatus` and `ComponentStatus` nested messages providing version-specific and overall component lifecycle information (status, repository status, indexed dates, error handling)
- Added `ComponentsStatusResponse` message for bulk component status responsesNotes
|
There was a problem hiding this comment.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Duplicate comments:
In `@protobuf/scanoss/api/components/v2/scanoss-components.proto`:
- Around line 225-226: Replace the triple-slash doc comment before the
ComponentStatus field—currently "/// Information about the current development
status of the component"—with a standard proto comment (e.g., use "//
Information about the current development status of the component" or a block
comment) so the generated OpenAPI/Swagger title no longer gets a leading "/";
then regenerate the swagger output so the corrected comment is reflected.
- Line 221: Update ComponentStatus.error_code to use the fully qualified type
name like VersionStatus does: replace the short reference common.v2.ErrorCode
with scanoss.api.common.v2.ErrorCode on the ComponentStatus.message (symbol:
ComponentStatus.error_code) and remove any spurious double space in the optional
field declarations (e.g., change "optional string" to "optional string") so the
proto uses consistent, fully-qualified references and has correct spacing.
In `@protobuf/scanoss/api/components/v2/scanoss-components.swagger.json`:
- Around line 839-848: The proto enum ErrorCode in scanoss-common.proto must add
a zero-valued sentinel (e.g., UNSPECIFIED = 0) as the first enum member so unset
optional error_code does not default to INVALID_PURL; update ErrorCode to begin
with UNSPECIFIED (matching v2StatusCode pattern), then regenerate the
OpenAPI/Swagger so v2ErrorCode reflects the new enum order and includes
UNSPECIFIED as the first value.
- Around line 783-820: The example for v2ComponentsStatusResponse omits the
required "status" property defined by the schema; update the example object
inside v2ComponentsStatusResponse to include a "status" field that matches the
v2StatusResponse definition (e.g., status.code, status.message or equivalent
fields used by v2StatusResponse) alongside the existing "components" array so
the example reflects the full schema.
- Around line 704-710: Remove the stray leading "/" from the title on the
component_status schema (the title under ComponentStatusResponseComponentStatus)
by editing the title string to "Information about the current development status
of the component", and add a top-level "status" envelope to the
v2ComponentStatusResponse definition that references v2StatusResponse (i.e.,
include "status": { "$ref": "#/definitions/v2StatusResponse" }) and update the
v2ComponentStatusResponse example to include a matching "status" object so the
response follows the same envelope pattern as other top-level responses.
Suggested Changelog EntriesBased on the changes in this PR, here are the suggested entries for the `[Unreleased]` section of `CHANGELOG.md`: ```markdown [Unreleased]Added
|
There was a problem hiding this comment.
♻️ Duplicate comments (5)
protobuf/scanoss/api/components/v2/scanoss-components.swagger.json (3)
704-707:⚠️ Potential issue | 🟡 MinorRemove the leading “/” in the component_status title.
Line 706 shows a leading “/” in the title, caused by the
///doc comment in the proto. Fix the proto comment and regenerate.✅ Suggested fix in proto (regenerate swagger)
- /// Information about the current development status of the component + // Information about the current development status of the component🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@protobuf/scanoss/api/components/v2/scanoss-components.swagger.json` around lines 704 - 707, The OpenAPI title for "component_status" includes an unintended leading "/" due to the proto doc comment using `///`; remove the extra slash from the proto comment that documents ComponentStatusResponseComponentStatus (i.e., change `/// / Information about...` to `/// Information about...` or use a standard comment without the leading slash), then regenerate the swagger JSON so the "component_status" title no longer starts with "/".
783-820:⚠️ Potential issue | 🟡 MinorFix the response title and example for v2ComponentsStatusResponse.
The title still says “Component Statistics response data,” and the example omits the top-level
statusproperty declared in the schema.✅ Suggested swagger fix (or regenerate after proto update)
- "title": "Component Statistics response data (JSON payload)" + "title": "Component Status response data (JSON payload)" ... - "example": { "components": [ ... ] } + "example": { + "components": [ ... ], + "status": { + "status": "SUCCESS", + "message": "Component status successfully retrieved" + } + }🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@protobuf/scanoss/api/components/v2/scanoss-components.swagger.json` around lines 783 - 820, Update the v2ComponentsStatusResponse schema: change its title from "Component Statistics response data (JSON payload)" to a more accurate value like "Components status response" and modify the example payload to include the top-level "status" object matching the schema (v2StatusResponse) alongside the existing "components" array; ensure the example structure and title are consistent with the definition referenced by v2ComponentsStatusResponse.
839-848:⚠️ Potential issue | 🟠 MajorAdd an UNSPECIFIED zero-value to v2ErrorCode to avoid “no error” = INVALID_PURL.
With
INVALID_PURLas the zero value, unseterror_codefields serialize indistinguishably from a real INVALID_PURL error in proto3 JSON. Add a zero-value sentinel in the source enum and regenerate the swagger.✅ Suggested enum shape (update in scanoss-common.proto and regenerate)
- INVALID_PURL = 0; - COMPONENT_NOT_FOUND = 1; - NO_INFO = 2; - INVALID_SEMVER = 3; + ERROR_CODE_UNSPECIFIED = 0; + INVALID_PURL = 1; + COMPONENT_NOT_FOUND = 2; + NO_INFO = 3; + INVALID_SEMVER = 4;Run this to verify the current enum definition in the shared proto:
#!/bin/bash # Locate ErrorCode enum in common proto rg -n 'enum\s+ErrorCode' protobuf/scanoss/api/common/v2/scanoss-common.proto # Inspect surrounding lines sed -n '1,200p' protobuf/scanoss/api/common/v2/scanoss-common.proto🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@protobuf/scanoss/api/components/v2/scanoss-components.swagger.json` around lines 839 - 848, The v2ErrorCode enum currently uses INVALID_PURL as the implicit zero value causing unset fields to appear as INVALID_PURL; update the source proto enum (ErrorCode in scanoss-common.proto) to add a zero-value sentinel like UNSPECIFIED = 0 as the first enum member, shift the existing values (e.g., INVALID_PURL, COMPONENT_NOT_FOUND, NO_INFO, INVALID_SEMVER) to non-zero numbers, then regenerate the swagger (scanoss-components.swagger.json) so v2ErrorCode reflects the new UNSPECIFIED zero-value; ensure references to ErrorCode/v2ErrorCode in code and docs still compile after regeneration.protobuf/scanoss/api/components/v2/scanoss-components.proto (2)
224-227:⚠️ Potential issue | 🟡 MinorReplace the triple-slash doc comment to avoid the leading “/” in Swagger.
Line 226 still uses
///, which renders a leading “/” in the generated Swagger title.✅ Suggested fix
- /// Information about the current development status of the component + // Information about the current development status of the component🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@protobuf/scanoss/api/components/v2/scanoss-components.proto` around lines 224 - 227, The doc comment for the ComponentStatus field uses a triple-slash (///) which causes a leading "/" in generated Swagger; change the triple-slash comment to a standard protobuf comment (//) for the ComponentStatus field (component_status = 5) so the description reads correctly in the generated docs.
230-242:⚠️ Potential issue | 🟡 MinorUpdate the response title and example to match the schema.
The comment still says “Component Statistics response data,” and the OpenAPI example omits the top-level
statusfield that exists in the message.✅ Suggested fix
- * Component Statistics response data (JSON payload) + * Component Status response data (JSON payload) ... - example: "{\"components\": [{\"purl\": \"pkg:npm/strive-molu-axios\",\"name\": \"strive-molu-axios\", \"requirement\": \"^0.0.1\", \"version_status\": {\"version\": \"0.0.1-beta.1\", \"status\": \"deleted\", \"indexed_date\": \"2024-06-21\", \"check_date\": \"2026-02-01\" }, \"component_status\": { \"status\": \"active\", \"first_indexed_date\": \"2022-03-01\", \"last_indexed_date\": \"2026-02-15\" } } ] }" ; + example: "{\"components\": [{\"purl\": \"pkg:npm/strive-molu-axios\",\"name\": \"strive-molu-axios\", \"requirement\": \"^0.0.1\", \"version_status\": {\"version\": \"0.0.1-beta.1\", \"status\": \"deleted\", \"indexed_date\": \"2024-06-21\", \"check_date\": \"2026-02-01\" }, \"component_status\": { \"status\": \"active\", \"first_indexed_date\": \"2022-03-01\", \"last_indexed_date\": \"2026-02-15\" } } ], \"status\": {\"status\": \"SUCCESS\", \"message\": \"Component status successfully retrieved\"} }" ;🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@protobuf/scanoss/api/components/v2/scanoss-components.proto` around lines 230 - 242, The message ComponentsStatusResponse has an outdated comment/title and the OpenAPI example omits the top-level status field; update the leading comment/title to reflect this is a Components Status response (or similar accurate name) and modify the json_schema example inside the option for ComponentsStatusResponse to include the top-level "status" object alongside "components" so the example matches the actual message schema (ensure fields match scanoss.api.common.v2.StatusResponse and the repeated components field).
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Duplicate comments:
In `@protobuf/scanoss/api/components/v2/scanoss-components.proto`:
- Around line 224-227: The doc comment for the ComponentStatus field uses a
triple-slash (///) which causes a leading "/" in generated Swagger; change the
triple-slash comment to a standard protobuf comment (//) for the ComponentStatus
field (component_status = 5) so the description reads correctly in the generated
docs.
- Around line 230-242: The message ComponentsStatusResponse has an outdated
comment/title and the OpenAPI example omits the top-level status field; update
the leading comment/title to reflect this is a Components Status response (or
similar accurate name) and modify the json_schema example inside the option for
ComponentsStatusResponse to include the top-level "status" object alongside
"components" so the example matches the actual message schema (ensure fields
match scanoss.api.common.v2.StatusResponse and the repeated components field).
In `@protobuf/scanoss/api/components/v2/scanoss-components.swagger.json`:
- Around line 704-707: The OpenAPI title for "component_status" includes an
unintended leading "/" due to the proto doc comment using `///`; remove the
extra slash from the proto comment that documents
ComponentStatusResponseComponentStatus (i.e., change `/// / Information
about...` to `/// Information about...` or use a standard comment without the
leading slash), then regenerate the swagger JSON so the "component_status" title
no longer starts with "/".
- Around line 783-820: Update the v2ComponentsStatusResponse schema: change its
title from "Component Statistics response data (JSON payload)" to a more
accurate value like "Components status response" and modify the example payload
to include the top-level "status" object matching the schema (v2StatusResponse)
alongside the existing "components" array; ensure the example structure and
title are consistent with the definition referenced by
v2ComponentsStatusResponse.
- Around line 839-848: The v2ErrorCode enum currently uses INVALID_PURL as the
implicit zero value causing unset fields to appear as INVALID_PURL; update the
source proto enum (ErrorCode in scanoss-common.proto) to add a zero-value
sentinel like UNSPECIFIED = 0 as the first enum member, shift the existing
values (e.g., INVALID_PURL, COMPONENT_NOT_FOUND, NO_INFO, INVALID_SEMVER) to
non-zero numbers, then regenerate the swagger (scanoss-components.swagger.json)
so v2ErrorCode reflects the new UNSPECIFIED zero-value; ensure references to
ErrorCode/v2ErrorCode in code and docs still compile after regeneration.
ℹ️ Review info
Configuration used: defaults
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
api/componentsv2/scanoss-components.pb.gois excluded by!**/*.pb.go
📒 Files selected for processing (2)
protobuf/scanoss/api/components/v2/scanoss-components.protoprotobuf/scanoss/api/components/v2/scanoss-components.swagger.json
…. Forced Snake case for keys
agustingroh
force-pushed
the
SupportForComponentHealth
branch
from
c3ee7b9 to
244b6cf
Compare
agustingroh
force-pushed
the
SupportForComponentHealth
branch
from
244b6cf to
18c9e16
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary by CodeRabbit