Bug Report
Steps to Reproduce:
POST /calm/namespaces/{ns}/architectures/{id}/versions/{v} (or the pattern/timeline equivalent) with a request body whose embedded *Json field is malformed JSON — e.g. {"name":"x","description":"y","architectureJson":"{ not json"}.- The Mongo path eventually calls
Document.parse() on that field; the Nitrite path attempts a similar parse.
- The resulting
com.mongodb.util.JsonParseException bubbles up to the resource layer because the try { … } block on the versioned-create / versioned-update handlers does not catch it.
Expected Result:
HTTP 400 with a stable, non-echoing error body — consistent with how the namespace-create endpoints already handle the same exception (e.g. ArchitectureResource.createArchitectureForNamespace lines 113–114, TimelineResource.createTimelineForNamespace lines 92–94).
Actual Result:
HTTP 500 (uncaught exception). The error body is whatever Quarkus surfaces by default.
Related defect on the namespace-create endpoints that do handle it: the invalid*JsonResponse(...) helpers are called with namespace (the path param), not the JSON payload, so the 400 body reads e.g. "The architecture JSON could not be parsed: my-namespace". The helpers also embed user input directly into the response body, which is a small leakage risk for large or sensitive payloads.
Examples in main post-#2496:
ArchitectureResource.java:113–114 — invalidArchitectureJsonResponse(namespace)TimelineResource.java:93–94 — invalidTimelineJsonResponse(namespace) (matching the existing pattern)- equivalent in
PatternResource
- versioned POST/PUT in
ArchitectureResource, PatternResource, and TimelineResource all omit the JsonParseException catch
Environment:
calm-hub on main after PR #2496 lands.
Additional Context:
Surfaced during the pre-PR review of #2496 and re-flagged by Copilot review feedback on the same PR. #2496 deliberately matched the existing ArchitectureResource pattern in the new TimelineResource rather than fixing the gap in one resource alone (which would have created idiomatic drift). This issue exists to track the project-wide fix across architecture / pattern / timeline endpoints in one PR.
Suggested fixes:
- Versioned POST and PUT handlers: catch
JsonParseException, return 400 mirroring the namespace-create handler.
invalid*JsonResponse(...): either pass the (sanitized) JSON, or — preferably — return a generic message that doesn't echo user input. Fix the misleading parameter name and call sites.- Add integration coverage that asserts 400 (not 500) on a malformed-JSON POST and PUT for each of the three resources.
Bug Report
Steps to Reproduce:
POST /calm/namespaces/{ns}/architectures/{id}/versions/{v}(or the pattern/timeline equivalent) with a request body whose embedded*Jsonfield is malformed JSON — e.g.{"name":"x","description":"y","architectureJson":"{ not json"}.Document.parse()on that field; the Nitrite path attempts a similar parse.com.mongodb.util.JsonParseExceptionbubbles up to the resource layer because thetry { … }block on the versioned-create / versioned-update handlers does not catch it.Expected Result:
HTTP 400 with a stable, non-echoing error body — consistent with how the namespace-create endpoints already handle the same exception (e.g.
ArchitectureResource.createArchitectureForNamespacelines 113–114,TimelineResource.createTimelineForNamespacelines 92–94).Actual Result:
HTTP 500 (uncaught exception). The error body is whatever Quarkus surfaces by default.
Related defect on the namespace-create endpoints that do handle it: the
invalid*JsonResponse(...)helpers are called withnamespace(the path param), not the JSON payload, so the 400 body reads e.g."The architecture JSON could not be parsed: my-namespace". The helpers also embed user input directly into the response body, which is a small leakage risk for large or sensitive payloads.Examples in
mainpost-#2496:ArchitectureResource.java:113–114—invalidArchitectureJsonResponse(namespace)TimelineResource.java:93–94—invalidTimelineJsonResponse(namespace)(matching the existing pattern)PatternResourceArchitectureResource,PatternResource, andTimelineResourceall omit theJsonParseExceptioncatchEnvironment:
calm-hubonmainafter PR #2496 lands.Additional Context:
Surfaced during the pre-PR review of #2496 and re-flagged by Copilot review feedback on the same PR. #2496 deliberately matched the existing
ArchitectureResourcepattern in the newTimelineResourcerather than fixing the gap in one resource alone (which would have created idiomatic drift). This issue exists to track the project-wide fix across architecture / pattern / timeline endpoints in one PR.Suggested fixes:
JsonParseException, return 400 mirroring the namespace-create handler.invalid*JsonResponse(...): either pass the (sanitized) JSON, or — preferably — return a generic message that doesn't echo user input. Fix the misleading parameter name and call sites.