JSON splitter last week was working correctly.
Pipeline was not edited, JSON format did not change, and yet Pipeline is crashing indicating error that JSON splitter is expecting list not an object. Before 17th of Feb it was working perfectly fine. was something changed in snap architecture?
“Failure: Json Splitter expects a list, Reason: Found an object of type class java.util.LinkedHashMap, Resolution: The path $.data needs to refer to a list in the incoming document”
Hi Dabal,
JSON splitter is expecting list not an object, for example if the input is an object “data”: {“test1”:123}, JSON splitter will fallout because it is needed to be in array “data”: [{“test1”:123}]. You can use sl.ensureArray expression (Confluence) in Mapper snap before JSON splitter, to solve this issue.
Example: sl.ensureArray($data) - If it is an array will return unchanged, otherwise it should return the argument in an array.
Let me know if this helps you.
BR,
Ivica
1 Like
Is $.data[*] the correct path?
Try $data[*]
but why it was working more than one year, it was still working on Thursday, and today it is not working?
In release notes I see that Snaplogic was making some changes in JSON Splitter Snap - can this be a reason? Coincidence ?
no difference, even if I use get
Kindly post a screenshot of pipeline validation before the JSON splitter snap
Thanks
The object $data is an instance of Object not an array…
Place a mapper before the JSON splitter then set mapper as pass through enabled
Thanks it seems to work!
Do you know why it was working since like always, till last Thursday 16th of Feb and now it is not? Json is the same structure… It was going smoothly before. This is strange for me, my colleague has the very same issue with different pipeline, different json file, also there was a scheduled task last week and it went smoothly, today he has the same error message…
Using jsonPath in the JSON splitter snap will do the work without the additional mapper
I Would prefer this solution 
jsonPath($, “$.data[*]”)
There’s a regression in the snap for this undocumented behavior. My apologies. We’re fixing it.
To clarify: this regression was introduced in the 431patches19359 patch version, and also exists in main19844 (the Feb 2023 GA version) and in 432patches19918. I recommend rolling back to main18944 (the Nov 2022 GA version) until we deploy a new patch to fix this.
2 Likes
You see, I was right that snap is not working as it was before 
1 Like
Thank you for this information!
I thought I’m loosing my mind
Hi Sir Patrick, any updates when the patch fix will be available?
I’ve seen that it is already working correctly as before because I had to reverse all changes 
, so I assume this is already done. At least on PaaS… @ptaylor please confirm?
@alchemiz @dabalka Yes, sorry. We deployed patch 432patches19974 last week to fix the use case you (and others) reported. This morning we deployed a new patch, 432patches20062, which addressed a couple of other use cases where the behavior wasn’t backward compatible. Both patches were deployed to both the Latest and Stable distributions, so if you’re on version 4.32 of the platform, you should find that the pack has been automatically upgraded.
1 Like