Open SirWumpus opened 7 years ago
you are correct. what should happen is when the input ends, it should check if the parser is in a valid end state, and if not, emit an error.
Since it's been like this a long time, there maybe cases where this is what you want (for example, streaming from a live connection, not a file, and the connection drops) So I'd publish this as a breaking change.
If you make a PR that adds a option (enabled by default) for an error in this case, then I would gladly merge it!
I think #117 might fix this. Would you try that code to see if it works?
That PR could be updated to enable the feature behind an option. Also, I think that failing test is just because it's supposed to error but the error isn't being caught and tested in the test.
that PR does need a small update to give correct stream behaviour. thanks @doowb
Opening the outer most JSON array and failing to terminate it should generate a parsing error and non-zero exit code. Instead its assuming the opening square bracket indicates an empty array.
Similarly open square, open curly does not generate an error:
While starting a key with an open double-quote, will throw an error:
The knock on effect of this is for Node CLI tools, that use JSONStream, used in a shell pipe line will incorrectly report success for an erroneous parse state (
'['
and'[ {'
) .Real life example:
Using
JSONStream
in anamqppub
CLI that consumes JSON input and publishes to a AMQP exchange fails to return a non-zero exit code, because no error is raised by JSONStream for being in an incomplete parse state. When used in a shell pipeline, the exit code of the end of the pipe signals whether the pipeline terminated normally or not.So if a tool to decode CDR files to JSON and publish them has an error on the first CDR file, first CDR record, after it has sent the opening square bracket '[' to
amqppub
, breaks the pipeline with the stream in an invalid parse state, yetamqppub
exits with zero (0), because JSONStream didn't raise a parse error.