grpc: System.InvalidOperationException: 'Nullable object must have a value.' in DefaultDeserializationContext
What version of gRPC and what language are you using?
NuGet package Grpc 2.27.0 in C#
What operating system (Linux, Windows,…) and version?
Windows 10 64bit
What runtime / compiler are you using (e.g. python version or version of gcc)
.NET Framework 4.6.1
What did you do?
Connect to a gRPC Server using plain text.
What did you expect to see?
Connection successful
What did you see instead?
Since 2.23, it happens to me from time to time that I get an InvalidOperationException saying that the nullable object must have a value. This seems to happen in the Grpc.Core.Internal.DefaultDeserializationContext
:
public void Initialize(IBufferReader bufferReader)
{
this.bufferReader = GrpcPreconditions.CheckNotNull(bufferReader);
this.payloadLength = bufferReader.TotalLength.Value; // payload must not be null
}
The Problem is that at runtime, the value of the TotalLength is indeed null. Grpc does not catch this error message and the exception eventually pops up at the surface, telling me that the connection failed at all ports. Do you have an idea what scenario could lead to the payload being null? Could you raise a specific exception in that case?
This error may happen spontaneously and then disappear from one moment to another without any change in the code or even without restarting the application. However, since the bufferReader
is actually a wrapper around some native object, I can’t really debug what could be wrong here.
Anything else we should know about your project / environment?
I am using gRPC with protobuf-net instead of the Google Protobuf implementation both at the client and at a server-side. However, I check that all serialized byte arrays are not null. Clients written in Java can communicate with my server.
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Comments: 25 (8 by maintainers)
In the hope it helps somebody in the future. When you receive this exception on the client:
Status(StatusCode="Unimplemented", Detail="", DebugException="Grpc.Core.Internal.CoreErrorDetailException: {"created":"@1670095245.871000000","description":"Error received from peer ipv4:127.0.0.1:63990","file":"..\..\..\src\core\lib\surface\call.cc","file_line":953,"grpc_message":"","grpc_status":12}")
and run the code under a debugger you will get to the exact same behavior as described in this issue.However in my case it had nothing to do with assembly versions or so, on the server side the base was simply not added to the services of the server (BindService). So the discussion here was a complete red herring.
@jtattermusch Scratch all that, just realized my problem while refactoring to avoid naming. I had set up my Visual Studio projects to copy the resulting server exe into the client’s bin directory, but I had forgotten the exe.config that contained the assembly bindings.