Support for component health (components service)#62
Open
scanoss-qg wants to merge 7 commits intomainfrom
Open
Support for component health (components service)#62scanoss-qg wants to merge 7 commits intomainfrom
scanoss-qg wants to merge 7 commits intomainfrom
Conversation
📝 WalkthroughWalkthroughAdded two new Components RPCs and HTTP endpoints to fetch single-component and bulk component status; introduced new protobuf and Swagger message/definition types for per-component and per-version status, repository/indexing dates, and optional error codes/messages. Changes
Sequence Diagram(s)sequenceDiagram
participant Client
participant API as API Gateway
participant Components as Components Service
participant Indexer as Indexing/Status Store
Client->>API: GET /v2/components/status/component?purl=...
API->>Components: GetComponentStatus(request)
Components->>Indexer: Query component & version status by purl
Indexer-->>Components: status payload (component_status, version_status)
Components-->>API: ComponentStatusResponse
API-->>Client: 200 OK + JSON
rect rgba(0,128,0,0.5)
note over Components,Indexer: Bulk flow (POST /v2/components/status/components) uses 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
| /* | ||
| * Component lifecycle status | ||
| */ | ||
| message ComponentStatusResponse { |
Contributor
There was a problem hiding this comment.
This is missing two fields: requirement and version.
Contributor
Author
There was a problem hiding this comment.
I think that only the requirement should be included at the root. Version should be on VersionStatus.
| // Name of the component | ||
| string name = 2; | ||
| // Component version status | ||
| message VersionStatus { |
Contributor
There was a problem hiding this comment.
Are you going to store the requirement and version fields in the root?
| message ComponentStatusResponse { | ||
| option (grpc.gateway.protoc_gen_openapiv2.options.openapiv2_schema) = { | ||
| json_schema: { | ||
| example: " { \"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\" } } " ; |
Contributor
There was a problem hiding this comment.
make sure to update the json with the new schema details (i.e. version, etc.)
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.
Comment on lines
+835
to
+845
| "v2ErrorCode": { | ||
| "type": "string", | ||
| "enum": [ | ||
| "INVALID_PURL", | ||
| "COMPONENT_NOT_FOUND", | ||
| "NO_INFO", | ||
| "INVALID_SEMVER" | ||
| ], | ||
| "default": "INVALID_PURL", | ||
| "description": "Error code enum for component analysis operations.\nRepresents the various error conditions that can occur during component processing and validation.\n\n - INVALID_PURL: The provided Package URL (PURL) is invalid or malformed\n - COMPONENT_NOT_FOUND: The requested component could not be found in the database\n - NO_INFO: No information is available for the requested component\n - INVALID_SEMVER: The provided semantic version (SemVer) is invalid or malformed" | ||
| }, |
There was a problem hiding this comment.
v2ErrorCode is missing an UNSPECIFIED (zero-value) sentinel, making "no error" indistinguishable from INVALID_PURL on the wire.
In proto3, the first enum value (ordinal 0) is the field's default and is omitted in JSON serialization. With INVALID_PURL as the first value, any response where error_code was never set (i.e., the success/no-error path) will serialize identically to a genuine INVALID_PURL error — consumers cannot tell them apart.
Compare with v2StatusCode, which correctly uses UNSPECIFIED as the zero/default value.
The proto source must be fixed first; the swagger is generated from it.
enum ErrorCode {
- 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;
}🤖 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 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.
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.
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
2 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