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

  1. Ensure the GarnetServer instance is constructed with standard RESP session providers (GarnetServerOptions with standard providers, or manually call AddSession for WireFormat.ASCII).
  2. If using an embedded/custom server, check that GetSessionProviders() contains WireFormat.ASCII before starting the TCP listener.
  3. 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

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


AI-assisted analysis of microsoft/garnet@951b0fc683 (2026-08-13). Data as JSON: /api/errors/e370d2c5735011df. Report an issue: GitHub.