0rpc/zerorpc-node

Large numbers passed in JSON arguments are corrupted

Closed this issue · 4 comments

I've just noticed that some large numbers (facebook ids, in this case) don't make it over the wire intact. They are silently converted into another number in transit.

Example server:

var zerorpc = require("zerorpc");

var server = new zerorpc.Server({
    echo: function(obj, reply) {
        reply(null, obj);
    },
});

server.bind("ipc:///tmp/ipctest");

server.on("error", function(error) {
    console.error("RPC server error:", error);
});

// Workaround to keep the server from being garbage collected... 
setInterval(function() {
    server;
},1000);

Example client:

var zerorpc = require("zerorpc");

var client = new zerorpc.Client();
client.connect("ipc:///tmp/ipctest");

client.on("error", function(error) {
    console.error("RPC client error:", error);
});

client.invoke('echo', {id:100000886207365}, function(error,res,more){
    console.log(res);
});

The expected answer would be exactly what I plugged in, but I get back the following:

$ node zrpc-client.js
{ id: 1162654597 }

I can work around it by using JSON.stringify and JSON.parse to flatten all arguments before pushing them through zerorpc... but that seems pretty horrible to me. Should I need to do this?

So I dug a tiny bit deeper... and it looks like it's fixed by upgrading to msgpack2 version 0.1.10. That release bump should also go in your next release.

Looks like this was the culprit: JulesAU/node-msgpack@552c29a

Hey,

Thanks for looking into this. I just published zerorpc@0.9.1 on npm which includes the upgraded dependency on msgpack2.

Thanks for rolling this out... I wasn't looking forward to helping my team mates through a custom npm install for this.

This issue was reintroduced when the msgpack version was switched back to 0.1.8 (see commit referenced above for a fix). Setting it to > 0.1.10 fixes it again.

Let me know if I need to recreate an issue or if you can re-open it.