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.