Skip to content

Malformed stored version can permanently break custom check publish with an opaque 500 #483

Description

@prestoncabe

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.

Activity

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    • Status
      Done

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions