Log a warning and drop the message (the default).

On JetStream the message is also terminated, so the server stops redelivering it - a payload no codec can read will not decode any better on the next attempt, and leaving it unacknowledged would replay it every ackWait for as long as the consumer exists.

Republish the raw undecodable payload to subject, then drop it from this flow.

The dead-lettered message carries the original payload and headers plus the provenance headers in DeadLetterHeaders.

subject must be captured by a stream, and not by the one being consumed. On JetStream the dead letter is published as a JetStream message, and the original is terminated only once the server has acknowledged storing it - so a dead letter that never lands cannot take the original down with it. The flip side is that a dead-letter subject with no stream behind it holds every undecodable message unacknowledged for redelivery, and one the source stream captures - orders.dlq under an orders.> stream - feeds every dead letter straight back into the consumer that produced it, so a single undecodable message fills the stream. JetStream's subscribe and pull reject both up front rather than let you discover them one message at a time.

On core NATS there is no stream and no acknowledgement to wait for: the dead letter is a core publish, and reaches only whatever is listening on subject at that moment - so a subject nothing is subscribed to loses the message rather than keeping it for later. The feedback loop is the same one, though: a subscription over orders.> dead-lettering to orders.dlq receives its own dead letters, fails to decode them again and republishes them, at round-trip speed. Core subscribe, subscribeMessages and respond refuse that pairing at the call, which the two subjects decide between them without asking the server.