Support for component health (components service)#62
Support for component health (components service)#62scanoss-qg wants to merge 5 commits intomainfrom
Conversation
📝 WalkthroughWalkthroughAdded two new Components RPCs (GetComponentStatus GET /v2/components/status/component and GetComponentsStatus POST /v2/components/status/components) and new protobuf/Swagger types modeling 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 /components) follows same pattern with batched requests
end
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 3 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches🧪 Generate unit tests (beta)
⚔️ Resolve merge conflicts (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 |
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.
| message VersionStatus { | ||
| // Development status of the requested version of this component classified automatically | ||
| string status = 1; | ||
| // Raw status reported by the registry for this version | ||
| string repository_status = 2; | ||
| // Date that the component was indexed | ||
| string indexed_date = 3; | ||
| // Date that the status was checked | ||
| string check_date = 4; | ||
| // States if something went wrong while seatching the version of this 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.
VersionStatus is missing a version field.
The swagger example (and the proto's own openapiv2_schema example on line 188) includes "version": "0.0.1-beta.1" inside version_status, but the VersionStatus message has no version field defined. This means the API has no way to communicate which version the status pertains to.
🐛 Proposed fix: add the missing `version` field
message VersionStatus {
+ // Version of the component this status refers to
+ string version = 7;
// Development status of the requested version of this component classified automatically
string status = 1;
// Raw status reported by the registry for this version
string repository_status = 2;
// Date that the component was indexed
string indexed_date = 3;
// Date that the status was checked
string check_date = 4;
// States if something went wrong while searching the version of this component on DB
optional string error_message = 5 [json_name = "error_message"];
optional common.v2.ErrorCode error_code = 6 [json_name = "error_code"];
}Note: If you add the field, also update the swagger definition ComponentStatusResponseVersionStatus to include a version property.
📝 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.
| message VersionStatus { | |
| // Development status of the requested version of this component classified automatically | |
| string status = 1; | |
| // Raw status reported by the registry for this version | |
| string repository_status = 2; | |
| // Date that the component was indexed | |
| string indexed_date = 3; | |
| // Date that the status was checked | |
| string check_date = 4; | |
| // States if something went wrong while seatching the version of this component on DB | |
| optional string error_message = 5 [json_name = "error_message"]; | |
| optional common.v2.ErrorCode error_code = 6 [json_name = "error_code"]; | |
| } | |
| message VersionStatus { | |
| // Version of the component this status refers to | |
| string version = 7; | |
| // Development status of the requested version of this component classified automatically | |
| string status = 1; | |
| // Raw status reported by the registry for this version | |
| string repository_status = 2; | |
| // Date that the component was indexed | |
| string indexed_date = 3; | |
| // Date that the status was checked | |
| string check_date = 4; | |
| // States if something went wrong while searching the version of this component on DB | |
| optional string error_message = 5 [json_name = "error_message"]; | |
| optional 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 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.
There was a problem hiding this comment.
Typo: "seatching" → "searching"; prefer fully qualified type reference.
- Line 205: typo "seatching" should be "searching".
- Line 207:
common.v2.ErrorCodeworks via protobuf's scope resolution but is inconsistent with the rest of this file, which uses fully qualified names (e.g.,scanoss.api.common.v2.ComponentRequeston line 108). Usingscanoss.api.common.v2.ErrorCodewould be more consistent and less fragile.
,
Proposed fix
- // States if something went wrong while seatching the version of this component on DB
+ // States if something went wrong while searching the version of this 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.
| // States if something went wrong while seatching the version of this 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 version of this 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 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.
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.
| // 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).
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).
| "ComponentStatusResponseVersionStatus": { | ||
| "type": "object", | ||
| "properties": { | ||
| "status": { | ||
| "type": "string", | ||
| "title": "Development status of the requested version of this component classified automatically" | ||
| }, | ||
| "repository_status": { | ||
| "type": "string", | ||
| "title": "Raw status reported by the registry for this version" | ||
| }, | ||
| "indexed_date": { | ||
| "type": "string", | ||
| "title": "Date that the component was indexed" | ||
| }, | ||
| "check_date": { | ||
| "type": "string", | ||
| "title": "Date that the status was checked" | ||
| }, | ||
| "error_message": { | ||
| "type": "string", | ||
| "title": "States if something went wrong while seatching the version of this component on DB" | ||
| }, | ||
| "error_code": { | ||
| "$ref": "#/definitions/v2ErrorCode" | ||
| } | ||
| } | ||
| }, |
There was a problem hiding this comment.
VersionStatus schema is missing the version property shown in the example.
The example at lines 669–670 shows "version": "0.0.1-beta.1" inside version_status, but this definition has no version property. This will be corrected downstream once the proto VersionStatus message adds the missing field (see proto review comment).
🤖 Prompt for AI Agents
In `@protobuf/scanoss/api/components/v2/scanoss-components.swagger.json` around
lines 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.
| "component_status": { | ||
| "$ref": "#/definitions/ComponentStatusResponseComponentStatus", | ||
| "title": "/ Information about the current development status of the component" | ||
| } |
There was a problem hiding this comment.
Leading / in the title from /// comment in the proto.
Line 695 renders as "/ Information about the current development status of the component" because the proto source at line 226 uses /// (triple slash). Fix the proto comment to use // and regenerate.
Fix in the proto file (line 226)
- /// Information about the current development status of the component
+ // Information about the current development status of the component🤖 Prompt for AI Agents
In `@protobuf/scanoss/api/components/v2/scanoss-components.swagger.json` around
lines 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.
| "v2ComponentsStatusResponse": { | ||
| "type": "object", | ||
| "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" | ||
| } | ||
| } | ||
| ] | ||
| }, | ||
| "properties": { | ||
| "component_status": { | ||
| "type": "array", | ||
| "items": { | ||
| "type": "object", | ||
| "$ref": "#/definitions/v2ComponentStatusResponse" | ||
| }, | ||
| "title": "Component status" | ||
| }, | ||
| "status": { | ||
| "$ref": "#/definitions/v2StatusResponse", | ||
| "title": "Response status" | ||
| } | ||
| }, | ||
| "title": "Component Statistics response data (JSON payload)" | ||
| }, |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# First, let's look at the proto file to understand the structure
echo "=== Checking proto file ==="
cat protobuf/scanoss/api/components/v2/scanoss-components.proto | head -100Repository: scanoss/papi
Length of output: 3290
🏁 Script executed:
#!/bin/bash
# Search for the v2ComponentsStatusResponse definition in the proto
echo "=== Searching for v2ComponentsStatusResponse in proto ==="
rg -n 'v2ComponentsStatusResponse|json_name.*components' protobuf/scanoss/api/components/v2/scanoss-components.protoRepository: scanoss/papi
Length of output: 202
🏁 Script executed:
#!/bin/bash
# Check the swagger file for the exact structure of v2ComponentsStatusResponse
echo "=== Checking swagger structure ==="
sed -n '772,808p' protobuf/scanoss/api/components/v2/scanoss-components.swagger.jsonRepository: scanoss/papi
Length of output: 1170
🏁 Script executed:
#!/bin/bash
# Search for all json_name overrides in the proto
echo "=== All json_name overrides ==="
rg -B 5 -A 1 'json_name' protobuf/scanoss/api/components/v2/scanoss-components.protoRepository: scanoss/papi
Length of output: 2621
🏁 Script executed:
#!/bin/bash
# Check how the swagger handles component_status vs components
echo "=== Checking component_status and components usage ==="
rg -n '"component_status"|"components"' protobuf/scanoss/api/components/v2/scanoss-components.swagger.json | head -30Repository: scanoss/papi
Length of output: 415
Fix two issues in v2ComponentsStatusResponse.
- Title (line 807): Change "Component Statistics response data" to "Component Status response data". Update the proto source and regenerate the swagger.
- Property/wire-name mismatch (line 794): The swagger property is
component_status, but the proto'sjson_name = "components"override means the actual JSON payload uses"components"(confirmed by the example at line 775). The swagger spec does not respect this override. Either the protoc-gen-openapiv2 configuration needs adjustment, or the swagger must be manually corrected to use"components"as the property key to match the actual wire format.
🤖 Prompt for AI Agents
In `@protobuf/scanoss/api/components/v2/scanoss-components.swagger.json` around
lines 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.
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
| /* | ||
| * Component lifecycle status | ||
| */ | ||
| message ComponentStatusResponse { |
There was a problem hiding this comment.
This is missing two fields: requirement and version.
| // Name of the component | ||
| string name = 2; | ||
| // Component version status | ||
| message VersionStatus { |
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\" } } " ; |
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
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.
Summary by CodeRabbit