-- cannot read property 'name' of null about grpc-node

[murgatroid99]

I'm not entirely clear on what you're doing. When you say "we were passing a grpc.Metadata that was created by 1.8.0 to this client implementation using 1.7.3", do you mean that you are taking a Metadata object created from grpc 1.8.0, and passing it to a grpc 1.7.3 function? If so, that would cause the problem you are seeing. I am not really sure why you would be seeing the same error if you are using the same grpc library for both. Is it possible that you are loading two separate instances of grpc 1.8.0?

[ntindall]

do you mean that you are taking a Metadata object created from grpc 1.8.0, and passing it to a grpc 1.7.3 function?

yes. that is what we were doing... it makes sense to me that this could cause problems, but I'm not sure this is the ideal world. It would be best if we had backwards compatibility here, right? to be clear:

     const metadata = new grpc.Metadata(); // grpc 1.8.0 metadata

     if (typeof context.requestId === 'string') {
       metadata.set('request_id', context.requestId);
     }
     
     // promisified grpc 1.7.3 function
     plaidGrpcService.client()
     .nameOfPromisifiedMethodAsync(requestObject, metadata, {
       deadline: plaidGrpcService.defaultDeadline(),
     })
     .then(res => {
       // business logic.
     })

Is it possible that you are loading two separate instances of grpc 1.8.0?

I think that could be possible. Let me try to reproduce it again with everything using 1.8.0.

In general @murgatroid99, is this a supported use case or should we be aiming to have everything using the same grpc version?

---

Edit: OK, I tried it again, this time ensuring there was no duplicate instance of grpc, and this is no longer a problem. Do you have any ideas about why this fixes it?

[murgatroid99]

For the foreseeable future, you should not expect to be able to mix together objects from different instances of the gRPC library. It would make type checking a nightmare, and some types are implemented with underlying C structures and therefore simply would not be portable at all.

[ntindall]

Ok, thanks for your help @murgatroid99. I am wondering if there is anything that could be done in order to make the root cause here more obvious to others who maybe encountering this... Assuming the bug in arguejs were fixed, do you think this is a good failure mode?