Summary
versionForPublish in builder-api/src/main/java/org/acme/controller/EligibilityCheckResource.java now parses version strings read back from Firestore, not just the API-generated working version. A single published check document with a blank or non-numeric version field makes publishing that check throw NumberFormatException, and it stays broken on every retry.
Details
versionForPublish (EligibilityCheckResource.java:401) maps every published check's version through normalize, which does Integer.parseInt on each dot-separated segment:
return publishedChecks.stream()
.map(EligibilityCheck::getVersion)
.filter(Objects::nonNull)
.map(this::normalize)
...
filter(Objects::nonNull) guards against a missing field but not against "" or any non-numeric segment — "".split("\\.") yields [""], so Integer.parseInt("") throws.
The call site (EligibilityCheckResource.java:294) sits outside every try/catch in publishCustomCheck:
check.setVersion(versionForPublish(check.getVersion(), publishedChecks));
So the exception escapes the resource method and the client gets a bare 500 with no JSON body, unlike every other failure path in this method, which returns {"error": ...}.
Before the versioning change, only the working check's own API-generated version was parsed, so the parse could never see foreign data.
Impact
Low likelihood (requires an already-malformed published document), but the failure is permanent for that check — publish cannot succeed again until the bad document is fixed by hand — and it surfaces as an opaque 500.
Suggested fix
Either filter out unparseable versions inside versionForPublish (skip anything normalize cannot handle), or wrap line 294 in the same try/catch style as the surrounding blocks so it returns a structured error. Filtering is preferable: publishing should still work when one historical document is malformed.
Found during code review of the check-publish versioning change.
Summary
versionForPublishinbuilder-api/src/main/java/org/acme/controller/EligibilityCheckResource.javanow parses version strings read back from Firestore, not just the API-generated working version. A single published check document with a blank or non-numericversionfield makes publishing that check throwNumberFormatException, and it stays broken on every retry.Details
versionForPublish(EligibilityCheckResource.java:401) maps every published check's version throughnormalize, which doesInteger.parseInton each dot-separated segment:filter(Objects::nonNull)guards against a missing field but not against""or any non-numeric segment —"".split("\\.")yields[""], soInteger.parseInt("")throws.The call site (
EligibilityCheckResource.java:294) sits outside every try/catch inpublishCustomCheck:So the exception escapes the resource method and the client gets a bare 500 with no JSON body, unlike every other failure path in this method, which returns
{"error": ...}.Before the versioning change, only the working check's own API-generated version was parsed, so the parse could never see foreign data.
Impact
Low likelihood (requires an already-malformed published document), but the failure is permanent for that check — publish cannot succeed again until the bad document is fixed by hand — and it surfaces as an opaque 500.
Suggested fix
Either filter out unparseable versions inside
versionForPublish(skip anythingnormalizecannot handle), or wrap line 294 in the same try/catch style as the surrounding blocks so it returns a structured error. Filtering is preferable: publishing should still work when one historical document is malformed.Found during code review of the check-publish versioning change.