Error Codes

The error reference for the MassTransit.KubeMQ transport: the exception hierarchy, the validation messages thrown at bus startup, and the runtime triggers behind connection, timeout, and CQ request failures. For handling patterns — retries, native DLQ, and the _error / _skipped channels — see the Error Handling & DLQ guide.

Exception hierarchy

All transport exceptions derive from KubeMQTransportException, which itself extends MassTransit's MassTransitException. The base type carries optional Channel and ServerAddress properties for diagnostics, and three subtypes classify the failure. All four live in the MassTransit.KubeMQTransport.Exceptions namespace.

MassTransitException
└── KubeMQTransportException          (Channel, ServerAddress)
    ├── KubeMQTransportConfigurationException
    ├── KubeMQTransportConnectionException
    └── KubeMQTransportTimeoutException

Validation errors

KubeMQTransportOptions.Validate() runs automatically during bus startup and throws KubeMQTransportConfigurationException with one of these messages for an out-of-range value, so misconfiguration fails fast at boot.

You can run the same validation yourself before startup — useful in tests or a configuration smoke check:

using MassTransit.KubeMQTransport;
using MassTransit.KubeMQTransport.Exceptions;

try
{
    var options = new KubeMQTransportOptions { Port = 99999 };
    options.Validate();
}
catch (KubeMQTransportConfigurationException ex)
{
    // "Port is invalid: 99999 must be between 1 and 65535"
    Console.WriteLine(ex.Message);
}

Runtime error triggers

Fault metadata

When a message is faulted (after all retries are exhausted) and routed to {channel}_error, the transport stores fault metadata as KubeMQ tags. Read them on the error channel to understand what failed.

See also