Failing to fix a truncated string containing a delimeter like a colon :

[JpEncausse]

I give a try to handle partial JSON return from an LLM. But it fail on very simple content. May be I use it wrong ?

{"text":"🌶️ Here is a Poeme for you :

Library should simply close the quote then the accolade ...

{"text":"🌶️ Here is a Poeme for you :"}

But return Error: Object key expected at position 37

[josdejong]

It's not so trivial to repair as you may think 😉. It would be great to improve on this though. Help would be very welcome.

Related issues:

• Failing to fix a json string containing parenthesis ( or ) #126
• Failing when parsing double quotes inside a string which are followed by a Comma #129

[JpEncausse]

A very kludge workaround I found is to add a quote " at the end of my string ONLY IF it do NOT END with }
It seems the algorithm close many more case

[josdejong]

That's a smart workaround in case you know you have a truncated JSON document 👍

[hejtmii]

We are experiencing the same when receiving JSON content from AI (ChatGPT) via streaming, and in our case the strings in JSON contain sentences with commas etc.

It seems the problem is that it detects "delimiters" even within a string value, prematurely finishes the string by adding " and then continues thinking the next part is another key in the object

Regarding possible fixes:

• I don't see this kind of fix in the "documentation" of supported fixes, but "Repair truncated JSON" is there, so maybe you could just remove this fix support and then later re-introduce it in a more robust way?
• If the above is not possible for some reason (please add it to the docs), a configuration object for enabled/disabled fixes could help as a workaround that people could use until the issue is resolved

[JpEncausse]

@hejtmii Would be curious if you find a workaround. I'm still on my pseudo-hack for the same usecase than you.

[hejtmii]

@JpEncausse in our case we accumulate ChatGPT messages to a (growing) truncated JSON string. So our workaround is to "just" ignore the stages that throw while fixing the JSON and wait for some that passes. We always return JSON array, and only process "complete" objects from the array (basically always ignoring the last object from parsed array until the response is finished)

So in our case it is not really a blocking issue, I just wanted to share my findings and somewhat follow up with some thoughts on "It's not so trivial to repair as you may think"

I didn't want to implement some heuristic just for the sake of reducing the number of thrown and caught exceptions.

[DirkViljoen]

We've experienced the same with iso 8601 date strings which contain colons in the time part.

[josdejong]

Fixed now in [email protected].