PUT /cve/{id} should not unconditionally modify Cve-Id collection

[ElectricNroff]

cve-services/src/controller/cve.controller/cve.controller.js

Lines 599 to 600 in 416d2ab

	if (cveId.state === CONSTANTS.CVE_STATES.REJECTED) {
	result = await cveIdRepo.updateByCveId(id, { state: CONSTANTS.CVE_STATES.PUBLISHED })

versus

cve-services/src/controller/cve.controller/cve.controller.js

Line 424 in 416d2ab

await cveIdRepo.updateByCveId(cveId, { state: newCveState })

(etc.)

Successful calls to updateCve always result in cveIdRepo.updateByCveId(cveId, { state: newCveState }) but should do that only if the state of the CVE Record is being changed from PUBLISHED to REJECTED, or from REJECTED to PUBLISHED. Otherwise, in realistic situations in which there are tens of thousands of PUT /cve/{id} calls, there can be tens of thousands of modified items in the Cve-Id collection even though the state remained PUBLISHED. This can potentially result in a large amount of processing time for some Secretariat processes that care about modified CVE IDs.

More generally, updateCna is behaving optimally because it sets the state to PUBLISHED only if was previously REJECTED. rejectExistingCve makes superfluous changes to the Cve-Id collection if the CNA is replacing one REJECTED record with a different REJECTED record. rejectCVE makes superfluous changes to the Cve-Id collection if the CNA is entering a new REJECTED CVE Record when the CVE ID happens to be in the REJECTED state already. submitCVE makes superfluous changes to the Cve-Id collection if the Secretariat is entering a new REJECTED CVE Record when the CVE ID happens to be in the REJECTED state already.

And, of course, submitCna is correct because there is no way for the CVE ID to already be in the PUBLISHED state during a successful call.