Skip to main content
Version: v0.0.7

Interface: AckCorrelationWarning

The 'warning' payload the client emits for an ACK-correlation deviation (MLLP_ACK_UNMATCHED_CONTROL_ID, MLLP_ACK_AFTER_TIMEOUT).

A MllpWarning with two extra numeric fields. message is a frozen registry entry, byte-for-byte identical for a given code no matter what arrived on the wire, and everything input-derived is a number: the control ID's byte length and the elapsed time. A warning is a log line, so it carries no field content.

Example​

client.on('warning', (w: AckCorrelationWarning) => {
  logger.warn({ code: w.code, idBytes: w.controlIdBytes, elapsedMs: w.elapsedSinceSendMs });
});

Extends​

Properties​

byteOffset​

readonly byteOffset: number

Absolute stream byte offset where the anomaly was detected.

Inherited from​

MllpWarning.byteOffset

code​

readonly code: AckCorrelationCode

The correlation code this warning reports.

Overrides​

MllpWarning.code

connectionId​

readonly connectionId: string | undefined

Connection identifier. undefined at the framing layer; enriched by Connection before emitting upstream.

Inherited from​

MllpWarning.connectionId

controlIdBytes​

readonly controlIdBytes: number | null

Byte length of the control ID involved, or null when there was none to read. Control IDs are decoded latin1, so a code-unit count is a byte count.

elapsedSinceSendMs​

readonly elapsedSinceSendMs: number

Milliseconds between the send's write-flush (or its timeout, for a late ACK) and this warning.

message​

readonly message: string

Stable human-readable description. It carries structural facts (a byte offset, an accumulated size) and never a run of payload content.

Two codes carry exactly one input byte, and it is worth knowing which: MLLP_MISSING_LEADING_VT and MLLP_FS_WITHOUT_CR render the hex of the single byte found where a framing byte was expected, and on a stream that omits its leading VT that byte is the first byte of the unframed content. One byte, never a run, the same bound MllpFramingError.snippet carries. If that is more than your threat model allows, log code and byteOffset rather than message.

The ACK-correlation codes are stricter: their text comes from a frozen registry and does not vary with the wire at all.

Inherited from​

MllpWarning.message

timestamp​

readonly timestamp: Date

Wall-clock time at point of emission.

Inherited from​

MllpWarning.timestamp