Incomplete message parsing

[stevus]

I have a message body where the last couple of characters are being cut off. Our application using this library sees a Parse Error and the message is lost.

We are using v1.0.5 along with the C# Service Stack Server-Events library to send messages to this. The message we are sending is below:

id: 51
data: ProjectionChannel@OrderUpdated {"id":"55bf136a15e9415985aed687b5a13cdb","streamRevision":41}

Here is what is being parsed by the EventSource node library:

id: 51
data: ProjectionChannel@OrderUpdated {"id":"55bf136a15e9415985aed687b5a13cdb","streamRevision":4

This does not happen all the time, but it does happen frequently. Have any others seen this issue?

[aslakhellesoy]

Could it be that #108 (released in 1.0.6) introduced a regression?

Contributors: I think we need to add some fuzz testing.

[stevus]

We're using 1.0.5 so that wouldn't have caused our problem.

[rexxars]

Could you try upgrading to 1.0.6?

[stevus]

Upgrading to 1.0.6 has the same issue.

I can also see that a random message comes in before the properly formed one I am waiting for, and that is the exact character length of that characters missing. Could this be an issue with character chunking/content length?

69

id: 51
data: ProjectionChannel@OrderUpdated {"id":"55bf136a15e9415985aed687b5a13cdb","streamRevision":4

[rexxars]

This looks like chunked transfer encoding. We should have a look at handling this

[rexxars]

Actually, node automatically decodes chunked transfers, so this shouldn't be the case. Does this happen often enough that you could try replicating it in the browser with the native EventSource API?

Could you get hold of the response stream from something like curl?

[stevus]

Closing this issue - I don't think it is being caused by EventSource.

Just found that we are seeing two octets for a message, I imagine one is the octet meant for the following message and causing the first to be cutoff:

69
69
id: 51
data: ProjectionChannel@OrderUpdated {"id":"55bf136a15e9415985aed687b5a13cdb","streamRevision":41}

id: 52
data: ProjectionChannel@OrderUpdated {"id":"55bf136a15e9415985aed687b5a13cdb","streamRevision":42}

This explains why we see:

69
id: 51
data: ProjectionChannel@OrderUpdated {"id":"55bf136a15e9415985aed687b5a13cdb","streamRevision":4

[stevus]

We are thinking this might be a ServiceStack related bug, or some C# layer responsible for the chunked encoding.