Skip to content

Support for component health (components service)#62

Open
scanoss-qg wants to merge 5 commits intomainfrom
SupportForComponentHealth
Open

Support for component health (components service)#62
scanoss-qg wants to merge 5 commits intomainfrom
SupportForComponentHealth

Conversation

@scanoss-qg
Copy link
Contributor

@scanoss-qg scanoss-qg commented Feb 13, 2026

  • Adds project and version status of a given component
  • Adds granular error on component status

Summary by CodeRabbit

  • New Features
    • Added two endpoints under /v2/components/status: GET for single-component and POST for bulk queries.
    • Responses include detailed status payloads with version_status and component_status (status, repository/indexing dates, optional error info).
    • Introduced standardized error codes for status responses.
    • API now provides example JSON/OpenAPI schemas illustrating status payload structures.

@coderabbitai
Copy link

coderabbitai bot commented Feb 13, 2026

📝 Walkthrough

Walkthrough

Added 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

Cohort / File(s) Summary
Proto Definitions
protobuf/scanoss/api/components/v2/scanoss-components.proto
Added RPCs GetComponentStatus and GetComponentsStatus. Introduced messages: ComponentStatusResponse (with nested VersionStatus and ComponentStatus), and ComponentsStatusResponse; added fields for version_status and component_status.
Swagger Specification
protobuf/scanoss/api/components/v2/scanoss-components.swagger.json
Added endpoints /v2/components/status/component (GET) and /v2/components/status/components (POST). Added schema defs: v2ComponentStatusResponse, v2ComponentsStatusResponse, ComponentStatusResponseComponentStatus, ComponentStatusResponseVersionStatus, and v2ErrorCode enum; included examples and response mappings.

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
Loading

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~45 minutes

Possibly related PRs

Poem

🐰 nibbles a data leaf
New endpoints sprout in rows,
One to ask, one to list,
Status hops where the index goes,
I thump, I cheer, I twitch my nose.

🚥 Pre-merge checks | ✅ 3 | ❌ 1

❌ Failed checks (1 warning)

Check name Status Explanation Resolution
Merge Conflict Detection ⚠️ Warning ❌ Merge conflicts detected (9 files):

⚔️ CHANGELOG.md (content)
⚔️ api/componentsv2/scanoss-components.pb.go (content)
⚔️ api/componentsv2/scanoss-components.pb.gw.go (content)
⚔️ api/componentsv2/scanoss-components_grpc.pb.go (content)
⚔️ api/vulnerabilitiesv2/scanoss-vulnerabilities.pb.go (content)
⚔️ protobuf/scanoss/api/components/v2/scanoss-components.proto (content)
⚔️ protobuf/scanoss/api/components/v2/scanoss-components.swagger.json (content)
⚔️ protobuf/scanoss/api/vulnerabilities/v2/scanoss-vulnerabilities.proto (content)
⚔️ protobuf/scanoss/api/vulnerabilities/v2/scanoss-vulnerabilities.swagger.json (content)

These conflicts must be resolved before merging into main.
Resolve conflicts locally and push changes to this branch.
✅ Passed checks (3 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title 'Support for component health (components service)' clearly summarizes the main change: adding component health/status functionality to the components service API.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Post copyable unit tests in a comment
  • Commit unit tests in branch SupportForComponentHealth
⚔️ Resolve merge conflicts (beta)
  • Auto-commit resolved conflicts to branch SupportForComponentHealth
  • Create stacked PR with resolved conflicts
  • Post resolved changes as copyable diffs in a comment

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.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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: New v2ErrorCode enum looks reasonable.

The four error codes (INVALID_PURL, COMPONENT_NOT_FOUND, NO_INFO, INVALID_SEMVER) cover the expected failure modes. Note that default: "INVALID_PURL" is auto-generated from proto3's first-enum-value-is-default behavior — consider whether the first value should be an UNSPECIFIED sentinel (as done with v2StatusCode) to avoid accidentally defaulting to a meaningful error code.

Comment on lines 196 to 208
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"];
}
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🔴 Critical

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.

Suggested change
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.

Comment on lines 205 to 207
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟡 Minor

Typo: "seatching" → "searching"; prefer fully qualified type reference.

  1. Line 205: typo "seatching" should be "searching".
  2. Line 207: common.v2.ErrorCode works 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.ComponentRequest on line 108). Using scanoss.api.common.v2.ErrorCode would 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.

Suggested change
// 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.

Comment on lines 219 to 221
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟡 Minor

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
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟡 Minor

Copy-paste issues: wrong doc comment, double semicolon, and extra blank lines.

  1. Line 235: Comment says "Component Statistics response data" but this is the Status response. Should be "Component Status response data".
  2. Line 246: Double semicolon ;; — while protoc may tolerate this, it's unintended.
  3. 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).

Comment on lines +384 to +411
"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"
}
}
},
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🔴 Critical

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.

Comment on lines +693 to +696
"component_status": {
"$ref": "#/definitions/ComponentStatusResponseComponentStatus",
"title": "/ Information about the current development status of the component"
}
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟡 Minor

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.

Comment on lines +772 to +808
"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)"
},
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

🧩 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 -100

Repository: 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.proto

Repository: 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.json

Repository: 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.proto

Repository: 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 -30

Repository: scanoss/papi

Length of output: 415


Fix two issues in v2ComponentsStatusResponse.

  1. Title (line 807): Change "Component Statistics response data" to "Component Status response data". Update the proto source and regenerate the swagger.
  2. Property/wire-name mismatch (line 794): The swagger property is component_status, but the proto's json_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.

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🧹 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 for json_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 {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is missing two fields: requirement and version.

// Name of the component
string name = 2;
// Component version status
message VersionStatus {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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\" } } " ;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

make sure to update the json with the new schema details (i.e. version, etc.)

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🧹 Nitpick comments (2)
protobuf/scanoss/api/components/v2/scanoss-components.proto (2)

204-221: Minor comment/formatting issues in ComponentStatus block.

  1. Line 214: Comment says "searching for the version of this component" but ComponentStatus is version-agnostic — should be "searching for this component in the DB".
  2. Line 215: Double space between optional and string.
  3. 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., ComponentsStatisticResponse at 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.

Copy link
Contributor

@eeisegn eeisegn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants

Comments