fix(vmcomponents): handle NPE and ClassCastException in getVulIdsPerComponentVmId

[Shivamrut]

Summary

Fixes #2726 — SVM notifications are silently not updated after the json-simple library upgrade in commit cd53eed.

Root Cause

The bug was introduced when json-simple was upgraded to version 4.x (cd53eed). Two breaking changes affected getVulIdsPerComponentVmId in SVMSyncHandler.java:

1. NullPointerException — when the SVM API returns a JSON object that is missing the "id" field, json.get(VULNERABILITY_ID) returns null. The old code called .toString() directly on that result:

// OLD — crashes if "id" field is absent
JsonObject json = (JsonObject) id;
String vulId = json.get(SVMConstants.VULNERABILITY_ID).toString(); // NPE here

2. ClassCastException — json-simple 4.x now parses plain integers in a JSON array as BigDecimal (previously Long). The old code unconditionally cast every array element to JsonObject:

// OLD — crashes if element is a plain integer like 19936
JsonObject json = (JsonObject) id; // ClassCastException here

Both exceptions were caught by the surrounding catch (RuntimeException e) block and silently swallowed, returning an empty set. This caused vulnerability notifications to never be updated — exactly the symptom reported in #2726.

Fix

for (Object id : ids) {
    String vulId;
    if (id instanceof JsonObject) {
        Object vulIdObj = ((JsonObject) id).get(SVMConstants.VULNERABILITY_ID);
        if (vulIdObj == null) {
            continue;
        }
        vulId = vulIdObj.toString();
    } else {
        vulId = id.toString();
    }
    if (!StringUtils.isEmpty(vulId)) {
        vulIds.add(vulId);
    }
}

• If the element is a JsonObject, extract the "id" field safely with a null check.
• If the element is a primitive (BigDecimal, String, etc.), call id.toString() directly.

Why the Bug Was Not Reproduced Live

Reproducing this bug end-to-end requires a live SVM API endpoint (Siemens internal). Without access to that endpoint, the sync process fails at the HTTP request stage before ever reaching the buggy line. Instead, the bug was confirmed through:

1. Static code analysis — tracing the call chain from the scheduler through VMProcessor → SVMSyncHandler.getVulnerabilitiesByComponentId → getVulIdsPerComponentVmId, confirming the exact lines that throw.
2. Root-cause unit tests — two tests that directly prove the crash scenarios exist at the json-simple library level (no SVM access needed).

Tests

A new standalone test class SVMSyncHandlerVulIdsTest was added. It requires no CouchDB and no SVM endpoint — WireMock fakes the HTTP responses and Mockito mocks the DB handler.

Test	What it proves
rootCause_JsonObjectMissingKey_..._ThrowsNPE	json.get("id") returns null for a missing key; .toString() throws NPE. Directly replicates the old buggy line.
rootCause_PlainInteger_..._ThrowsClassCastException	json-simple 4.x parses integers as BigDecimal; casting to JsonObject throws ClassCastException.
testGetVulIds_ObjectsWithIdField_ReturnsVulIds	Normal path: objects with "id" field return 3 IDs correctly.
testGetVulIds_ObjectWithMissingIdField_ReturnsEmptyGracefully	Missing "id" field returns empty set without exception.
testGetVulIds_PlainIntegerIds_ReturnsVulIds	Definitive proof: old code returns empty set (ClassCastException caught); fixed code returns all 3 IDs. assertEquals(3, result.size()) fails on old code, passes on fix.

All 5 tests pass: Tests run: 5, Failures: 0, Errors: 0, Skipped: 0

[GMishx]

Changes looks good.

[GMishx]

@akshitjoshii please help test this PR.