You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When large messages are posted into a gitter channel they can be chunked before sending to the REST API. In this case, the message must be reassembled before parsing. It would be helpful to developers to call this out in the sample code. Even better, to show to the proper way to detect end-of-message.
The text was updated successfully, but these errors were encountered:
Understood... but, I'm actually not sure what the proper way to resolve this is. I resolved it myself by try/catch around a JSON.parse(msg) and building up the chunk if it fails, but that seems horrific. I didn't have time to look for a more elegant solution
The JSON stream returns messages as JSON objects that are delimited by newline (\n). Space + newline (\n) are sent as periodic "keep-alive" messages to tell clients and NAT firewalls that the connection is still alive during low message volume periods.
There may be some assumptions about whether more than one object can be sent in a single stream that need some testing. I may give it a try to see if I can come up with something robust.
When large messages are posted into a gitter channel they can be chunked before sending to the REST API. In this case, the message must be reassembled before parsing. It would be helpful to developers to call this out in the sample code. Even better, to show to the proper way to detect end-of-message.
The text was updated successfully, but these errors were encountered: