When a new call is created with a streaming request/non-streaming response, an initial message is sent immediately (before call.write() is ever explicitly invoked) with a blank value.
It isn't clear to me why initCall() should have this code path to ever send along initial arguments, since it seems that sending an initial message on a streaming request call is prohibited by the client API (the comment seems to corroborate that this is a generally-unexpected case, but doesn't make clear when it would be expected)
Minimal Example
Given the following service:
function concat(call, callback) {
var msgs = [];
call.on('data', function(msg) {
msgs.push(msg.content);
console.log('concat got data', msg, msg.content);
});
call.on('end', function() {
callback(null, {content: msgs.join('\n')});
});
}
function main() {
var server = new grpc.Server();
server.addProtoService(hello_proto.Concater.service, {concat: concat});
server.bind('0.0.0.0:50051', grpc.ServerCredentials.createInsecure());
server.start();
}
main();
Calling it as
var concat = Concater.concat(function (err, res) {
console.log(res)
});
concat.write({content: 'concat data 1'});
concat.write({content: 'concat data 2'});
concat.end();
Shows the following server logs:
concat got data { content: '' }
concat got data { content: 'concat data 1' } concat data 1
concat got data { content: 'concat data 2' } concat data 2
and returns {content: "↵concat data 1↵concat data 2"} to the client (note the leading newline)
Hey Grant, just following up on this again. Are you guys still using grpc-bus, and if so, is it looking like a good time to bring it up to date with the latest versions of everything?
When a new call is created with a streaming request/non-streaming response, an initial message is sent immediately (before
call.write()
is ever explicitly invoked) with a blank value.This seems to occur because of a faulty test for initial arguments in
Call.initCall()
-- even thoughargs
is "blank", it gets decoded as an empty buffer, which evaluates as truthy.It isn't clear to me why
initCall()
should have this code path to ever send along initial arguments, since it seems that sending an initial message on a streaming request call is prohibited by the client API (the comment seems to corroborate that this is a generally-unexpected case, but doesn't make clear when it would be expected)Minimal Example
Given the following service:
Calling it as
Shows the following server logs:
and returns
{content: "↵concat data 1↵concat data 2"}
to the client (note the leading newline)