chore(vulnerability):SP-4012 include component status in block responses

[agustingroh]

Summary by CodeRabbit

• New Features

  • API responses now include per-component error message and standardized error code fields for clearer error context.

• Documentation

  • API docs and examples updated to describe the new error fields and show error-case payloads.

• Chore

  • Added a 0.29.0 changelog entry, removed an EPSS example from 0.28.0, and added a v0.28.0...v0.29.0 comparison link.

[coderabbitai]

Caution

Review failed

The pull request is closed.

📝 Walkthrough

Walkthrough

Adds per-component error reporting by introducing error_message and error_code fields to ComponentVulnerabilityInfo and ComponentCpesInfo, updates OpenAPI/Swagger schemas and response examples, and documents the changes in the changelog under version 0.29.0.

Changes

Cohort / File(s)	Summary
Changelog CHANGELOG.md	Added Unreleased 0.29.0 entry documenting error_message and error_code additions and added comparison link (v0.28.0...v0.29.0).
Protobuf definitions & docs protobuf/scanoss/api/vulnerabilities/v2/scanoss-vulnerabilities.proto	Added optional string error_message = 5 and common.v2.ErrorCode error_code = 6 to ComponentCpesInfo and ComponentVulnerabilityInfo; updated OpenAPI json_schema blocks and examples to show per-component error contexts for CPE and vulnerability responses.
Swagger / OpenAPI JSON protobuf/scanoss/api/vulnerabilities/v2/scanoss-vulnerabilities.swagger.json	Added v2ErrorCode enum definition; extended v2ComponentCpesInfo and v2ComponentVulnerabilityInfo with error_message and error_code; updated response descriptions and examples to include error-case payloads.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Possibly related PRs

• chore(vulnerability):SP-4012 include component status in block responses #61 — Modifies the same protobuf/OpenAPI artifacts by adding error_message and error_code to component info objects and introducing the corresponding error enum.

Suggested reviewers

• eeisegn
• isasmendiagus

Poem

🐰 I nibble at schemas, add fields five and six,
error_message hums, error_code clicks.
Each component now speaks when lookups go wrong,
a gentle hop, a fix, and a tidy little song. ✨

🚥 Pre-merge checks | ✅ 2 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Title check	⚠️ Warning	The title mentions 'component status' but the actual changes add error_message and error_code fields to handle error contexts, not component status.	Update the title to accurately reflect the main change, such as 'chore(vulnerability): Add error fields to component responses' or 'chore(vulnerability): SP-4012 add error handling to component blocks'.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
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 chore/SP-4012-include-status-vulnerability-response

---

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

• X
• Mastodon
• Reddit
• LinkedIn

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

[coderabbitai]

Actionable comments posted: 3

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

protobuf/scanoss/api/vulnerabilities/v2/scanoss-vulnerabilities.swagger.json (1)

486-488: ⚠️ Potential issue | 🟡 Minor

Pre-existing: malformed keys "requirement=" and "version=" in example.

The example object at Lines 487–488 has "requirement=" and "version=" as keys (with trailing =). These should be "requirement" and "version". This originates from the proto file's example string.

🤖 Fix all issues with AI agents

In `@CHANGELOG.md`:
- Around line 10-16: Add the missing comparison link for the new release tag:
append a link entry for [0.29.0] at the bottom of CHANGELOG.md matching the
existing pattern (e.g., "[0.29.0]:
https://github.com/scanoss/papi/compare/v0.28.0...v0.29.0") so the release list
includes a proper compare URL for the 0.29.0 section.

In `@protobuf/scanoss/api/vulnerabilities/v2/scanoss-vulnerabilities.proto`:
- Line 254: The example JSON for ComponentsCpesResponse contains malformed keys
with stray equals signs; locate the example string (the example field inside the
ComponentsCpesResponse example literal) and remove the '=' characters from the
keys "requirement=" and "version=" so they become "requirement" and "version"
respectively (apply to both component objects in the example) to produce valid
JSON.
- Line 377: The JSON example in the description for
ComponentVulnerabilityResponse (and the duplicate in
ComponentsVulnerabilityResponse) incorrectly uses the CPE field name "cpes" due
to copy-paste; update those description strings to replace the "cpes":[...]
array with "vulnerabilities":[...] (and ensure the example vulnerability objects
match the expected vulnerability schema if present) so the example reflects a
vulnerability response rather than a CPE response.

🧹 Nitpick comments (1)

protobuf/scanoss/api/vulnerabilities/v2/scanoss-vulnerabilities.swagger.json (1)

343-349: New error fields lack title/description in the schema.

All other properties in v2ComponentCpesInfo and v2ComponentVulnerabilityInfo include a title or description. The new error_message and error_code fields are missing them. Adding brief descriptions (e.g., "Error message describing why component processing failed" and "Error code categorizing the failure") would keep the schema documentation consistent.