Transport/send hangs when sending non-bencodable information outside of :value slot about nrepl HOT 3 CLOSED

@shen-tian You can take at this ticket as point if you want. It's somewhat related to what you've been working on recently.

from nrepl.

I have a guess at what this could be, though not sure if this still happens. Think it's related to differentiating between execution errors, disconnection errors, and actual breakages in nrepl.

@sanjayl doesn't seem to be active anymore, but tagging in case..

Will queue this up :)

from nrepl.

Finally had a dig into this one. I can replicate some behaviour (sending unencodable values, e.g. (Object.) in a message seem to cause a stall. This is not unique to the :value slot, though I think depending on where in the middleware stack this was done, print would have stringyfied any unencodable values in the :value slot. This is caused by how bencode/write-bencode works: it's recursive. Thus, it will start writing a map, before throwing an Exception that there's unecoded values inside. The fragment of a map, when sent, will cause the reader to stall waiting for "end of the map" that was never written.

• I didn't observe the "nothing sent on the network" effect, but this could be explained by .flush not being called after write.
• This did throw an exception for me on the middleware side, but not sure how visible this could have been from a client's point of view, as this error kind of wrecks the transport. This might also be affected by where the caught middleware is.

I checked the state of the library circa April 2017, and the analysis holds.

I've prepped a PR that makes the bencode writes fail cleaner.

BTW, does anyone know what's the deal with the -unencoded reading code here?

I can't find any reference to this in cider or cider-nrepl. What would write -unencoded?

from nrepl.