Skip to content

fix(cloudext): do not JSON-encode scalar String property values - #621

Open
JJUN99 wants to merge 2 commits into
OpenSPG:masterfrom
JJUN99:fix/string-double-json-encoding
Open

fix(cloudext): do not JSON-encode scalar String property values#621
JJUN99 wants to merge 2 commits into
OpenSPG:masterfrom
JJUN99:fix/string-double-json-encoding

Conversation

@JJUN99

@JJUN99 JJUN99 commented Aug 11, 2026

Copy link
Copy Markdown

Symptom

After ingesting data through the local builder (e.g. the supplychain example), every property value except id/name is stored in Neo4j double-encoded with surrounding quotes, e.g. transAmt = "102191" instead of 102191.

Because the reasoner reads raw property values, numeric functions in concept rules (sum, date_diff, ...) silently match 0 rows on such values, so all rule-derived virtual properties (e.g. fundTrans1Month) resolve to null. Returning the value directly raises:

NumberFormatException: For input string: "\"102191\""

Root cause

Neo4jSinkWriter.writeNode/writeEdge JSON-encode any value for which TypeChecker.isArrayOrCollectionOfPrimitives() returns false. That check returns false for scalar strings, and String is also missing from isPrimitiveOrWrapper(), so every string property gets passed through JSON.toJSONString() and picks up an extra pair of quotes. The write side and the read side (reasoner expects raw values) are asymmetric.

Fix

Treat scalar strings as storable as-is, and accept String elements inside arrays/collections for the same reason. Two lines in TypeChecker.

Verification

Applied this change to a running 0.8 server (hot-patched jar), rebuilt the supplychain example: all properties are stored clean, and concept rules computing over numeric string fields (fund transaction aggregates) produce correct non-null values.

Neo4jSinkWriter JSON-encodes any property value for which
TypeChecker.isArrayOrCollectionOfPrimitives() returns false. Since the
check returned false for scalar strings (and String was missing from
isPrimitiveOrWrapper), every string property was stored double-encoded
with surrounding quotes (e.g. 102191 -> "102191").

The reasoner reads raw property values, so numeric functions in concept
rules (sum, date_diff, ...) silently fail to match on such values and
rule-derived properties all resolve to null. Reading the value directly
raises NumberFormatException: For input string: '"102191"'.

Treat scalar strings as storable as-is, and accept String elements
inside arrays/collections for the same reason.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
@github-actions

github-actions Bot commented Aug 11, 2026

Copy link
Copy Markdown
Contributor

CLA Assistant Lite bot All contributors have signed the CLA ✍️ ✅

@JJUN99

JJUN99 commented Aug 11, 2026

Copy link
Copy Markdown
Author

I have read the CLA Document and I hereby sign the CLA

andylau-55 added a commit to OpenSPG/cla-assistant that referenced this pull request Aug 11, 2026
@JJUN99

JJUN99 commented Aug 11, 2026

Copy link
Copy Markdown
Author

Note on the failing License Validation check: it dies in the dependency-download step (license-eye dependency checkdependencies download error) before any license analysis runs. The same check also fails on unrelated PRs — e.g. the documentation-only #548 — and hasn't passed on any PR since early 2026, so this looks like a repo-wide CI issue rather than something related to this change (no new dependencies, license headers untouched).

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant