microsoft/garnet · error · Exception
Unsupported incoming wire format {protocol} {input}
Error message
Unsupported incoming wire format {protocol} {input} What it means
Garnet's TryCreateMessageConsumer hardcodes the wire protocol to WireFormat.ASCII (RESP) and looks up the corresponding session provider. If the ASCII provider is not registered in the server's session provider dictionary, it throws. This is a server initialization error, not a client protocol error — the incoming bytes are decoded only for logging. In a standard Garnet server the RESP provider is always registered; this throw indicates a non-standard or incomplete server setup.
Source
Thrown at libs/server/Servers/GarnetServerTcp.cs:327
/// <param name="bytes"></param>
/// <param name="networkSender"></param>
/// <param name="session"></param>
/// <returns></returns>
public bool TryCreateMessageConsumer(Span<byte> bytes, INetworkSender networkSender, out IMessageConsumer session)
{
session = null;
// We need at least 4 bytes to determine session
if (bytes.Length < 4)
return false;
WireFormat protocol = WireFormat.ASCII;
if (!GetSessionProviders().TryGetValue(protocol, out var provider))
{
var input = System.Text.Encoding.ASCII.GetString(bytes);
logger?.LogError("Cannot identify wire protocol {bytes}", input);
throw new Exception($"Unsupported incoming wire format {protocol} {input}");
}
if (!AddSession(protocol, ref provider, networkSender, out session))
throw new Exception($"Unable to add session");
return true;
}
/// <inheritdoc />
public void DisposeMessageConsumer(INetworkHandler session)
{
if (activeHandlers.TryRemove(session, out _))
{
Interlocked.Decrement(ref activeHandlerCount);
IncrementConnectionsDisposed();
try
{
session.Session?.Dispose();View on GitHub (pinned to 951b0fc683)
Solutions
- Ensure the GarnetServer instance is constructed with standard RESP session providers (GarnetServerOptions with standard providers, or manually call AddSession for WireFormat.ASCII).
- If using an embedded/custom server, check that GetSessionProviders() contains WireFormat.ASCII before starting the TCP listener.
- Verify you are not subclassing or wrapping GarnetServerTcp in a way that strips session provider registration.
Example fix
// before (custom server missing provider) var server = new GarnetServerTcp(options, logger); server.Start(); // after var server = new GarnetServerTcp(options, logger); server.AddSession(WireFormat.ASCII, new RespServerSessionProvider(...)); server.Start();
Defensive patterns
Strategy: validation
Validate before calling
// Verify providers before starting the listener
if (!server.GetSessionProviders().ContainsKey(WireFormat.ASCII))
throw new InvalidOperationException("RESP session provider not registered. Cannot accept connections."); Prevention
- In custom/embedded setups, verify GetSessionProviders() contains WireFormat.ASCII before calling Start().
- Use the standard GarnetServer constructors which register providers automatically.
- During shutdown, stop the TCP listener before clearing session providers.
When it happens
Trigger: Calling TryCreateMessageConsumer() when GetSessionProviders() does not contain WireFormat.ASCII. Occurs in custom/embedded server constructions that omit AddSession for RESP, or during teardown when providers have been removed but connections are still arriving.
Common situations: Building a custom GarnetServer without registering the standard RESP session provider; embedding Garnet in-process and misconfiguring the server pipeline; a race during server shutdown where providers are cleared before the listener fully stops.
Related errors
- Need to provide SslServerAuthenticationOptions when TLS is e
- Cannot provide SslServerAuthenticationOptions when TLS is di
- Need to provide SslClientAuthenticationOptions when TLS is e
- Cannot provide SslClientAuthenticationOptions when TLS is di
- Failed to connect at {endpoint}
AI-assisted analysis of microsoft/garnet@951b0fc683 (2026-08-13).
Data as JSON: /api/errors/e370d2c5735011df.
Report an issue: GitHub.