Replaying & publishing

Stream Trace can make two kinds of deliberate writes to NATS - replaying existing messages and publishing new ones. DLQ retry uses the same replay path. These actions create new NATS messages; they are permissioned and audited, and they do not rewrite application-owned stream or consumer configuration.

Replaying messages

Replay re-delivers messages for debugging. You can preview exactly what will happen before running it.

• Single or bulk - replay one message, a list of sequences, or everything matching your current filters, up to 500 messages per bulk request.
• Modes - republish publishes a new copy to the original subject, while consumer-scoped replay publishes a new copy to the replay subject declared in the target consumer’s metadata.
• Traceability - replayed messages carry Stream Trace headers (mode, original sequence, action ID, and reason) so you can tell them apart downstream.
• Preview - see the affected messages and target before executing.

Replaying requires the streams.messages.replay permission on the stream’s team.

Application change required for consumer-scoped replay. Set consumer metadata streamtrace.replay_subject, make sure the source stream captures that subject, make sure the target consumer is unfiltered or includes it in FilterSubject / FilterSubjects, and route it to the intended application handler. Stream Trace does not add this routing or edit the consumer. See the application integration checklist.

Publishing messages

Publish lets you inject test messages without leaving the UI.

• Single message - choose a subject, set headers, and write a payload.
• Bulk import - submit many messages at once; Stream Trace streams per-message progress and reports the success/failure of each.

Publishing requires the streams.messages.publish permission on the stream’s team.

Every publish and replay is written to the audit log with the actor, count, and outcome (succeeded, failed, or partial).