hmm I don't think we really have any asserts in place (delegating that to the user) so you may want to add a few for data being sent. One thing for debugging is to add if (msg == null) console.trace('wut') to axon in your node_modules so you can see where it was sent

re-open if it turns out to be axon but I think there's just some input getting messed

I had to step away but before I left I think I discovered that the buffer slice method is returning undefined! I really hope that isn't the case, I'll know more in a bit.

interesting! that would be weird, let me know if you find anything

Ha silly human make mistake.

Don't mind me, just...passing undefined to the send method.

It seems like it would be valuable to catch errors thrown during the deserialization process and enable the user of axon to catch those errors, rather than allowing the errors to halt the process. If I pulled something of that sort together, would you consider a pull request?

we should add asserts on input, and assume everything that gets in is valid. Even just assert(msg, 'message required')-ish asserts would be fine

+1 to assert. gogogo!

Alright, so I can make the tests fail by adding push.send(undefined); to line 16 of test.arg-types.js, simply because it causes the Unexpected token u SyntaxError.

The message is then encoded as a buffer containing 110000000b6a3a756e646566696e6564, which includes j:undefined. That means that, as confirmed by walking through with Node's debugger, the JSON.stringify line in node-amp-message is being passed undefined, which returns undefined, which is coerced into the string 'undefined'. I'm wondering whether this would be more suited for amp-message rather than axon, given that we're not currently looping through the args before buffering them in Socket#pack.

Also, given that send usually queues messages until the socket is actually ready, the error won't be thrown until the socket is ready which means I can't use assert.throws in the test case.

Anywho, I submitted pull request #125, but it'll need some revision.

for amp-message I'd almost rather just convert it to null and send that, since it's a valid value, just not ideal since it usually represents a user error. Maybe we should do that instead, there's nothing really wrong with sending undefined

Sounds good to me, 👍 for simplicity.

Alternatively, if we don't want to break some weird fringe case that somehow depends on the value being exactly undefined, we could just check if the arguments is equal to the string 'undefined' during the decode process.