Implement message logging functionality about nrepl HOT 10 OPEN

Yup, something I've wanted for a long time. I decided to do it as a proxy to prevent middleware ordering issues. This way you're sure you get the messages as they go over the wire. It's also nice that you can just pipe this to a file and share it with developers.

I have some ideas of where to take this, for now it's pretty basic. I mainly wanted to sort out the network part, the rest should be straightforward.

from nrepl.

Definitively I'm going to tackle something about this at #84, thanks for this issue, it's gonna be a good guide! o/

from nrepl.

I'm having some problems with it

1. When reading data, transport-read function is not available at FnTransport, can't see the data without changing the concrete transport implementation
2. send-fn at FnTransport is opaque

For 1, we could get the message after decoded and encode it again, but maybe it would not be representative enough of the received message.

For 2, I can compose the send-fn field (if FnTransport becomes a Record) with another function or using the reversed proposed solution for 1

Maybe would be better to snitch the data for in and out streams, but using this would require a global configuration instead per message.

Any other options to be suggested?

from nrepl.

When reading data, transport-read function is not available at FnTransport, can't see the data without changing the concrete transport implementation

So using something like logging-transport wrapper won't work? I think this was my original idea, but I didn't think much about this.

Maybe would be better to snitch the data for in and out streams, but using this would require a global configuration instead per message.

Yeah, perhaps that'd be better. We can just add some debug/verbose config to start-server and potentially support this via nrepl.config. That won't allow us to toggle dynamically the logging on/off, but it'd be a perfectly adequate solution for me.

from nrepl.

There's something about the scope of this issue which is not clear to me: what kind of issues are we trying to debug? Transport/serialization issues or applicative issues (non-conforming messages etc.)?
I believe we shouldn't try to address both of them at once.

from nrepl.

Transport/serialization issues or applicative issues (non-conforming messages etc.)?

Both. :-)

I believe we shouldn't try to address both of them at once.

Yeah, I agree with you, therefore my suggestion to split this PR in two and focus on the more common problem - the non-conforming messages.

Transport/serialization issues weren't very common in the past (mostly because everyone was using the same transport, which was pretty well-tested), but I assume that when we start rolling out new transports there might be some rough edges there, that's why some mechanism to monitor the serialization would be useful.

from nrepl.

I am trying to debug an issue where internal messages sent from Cursive (i.e. not sent by the user) are printed in the Cursive REPL, instead of hidden. Colin Fleming suspects the response message ID might not match the original request anymore, but to confirm that, we would need logs of the nREPL messages that are actually sent over the wire. Is there already a solution for this in nREPL?

from nrepl.

@devurandom Nope, we never managed to sort out message logging on the server-side. There was some work done in #87, but it was not completed.

from nrepl.

@plexus just created https://github.com/lambdaisland/nrepl-proxy as a debugging tool for nREPL connections! ❤️ 🎉

from nrepl.

Cool idea!

from nrepl.