vectordotdev/vector · error

Invalid `ack_decoding` config.

Error message

Invalid `ack_decoding` config.

What it means

handle_ack_request builds a decoder from the client's ack_decoding config for every ACK request. The DecodingConfig::build() call is unwrapped with expect("Invalid `ack_decoding` config."), so a config that cannot produce a decoder panics the connection handler. Note the .parse() afterwards is handled gracefully; only build() failure is fatal.

Solutions

  1. Fix the client's ack_decoding configuration to use a supported codec (e.g. json, text) with valid options.
  2. Validate the ack_decoding config once at connection setup (call build() early and reject the handshake) instead of panicking per message.
  3. Replace the expect with graceful handling: log and skip ACK processing (return None) when the decoder cannot be built.

Example fix

// before
.expect("Invalid `ack_decoding` config.")
.parse(request.into_data().into(), Default::default())
// after
let decoder = match ack_config.ack_decoding.build() {
    Ok(d) => d,
    Err(err) => {
        debug!(message = "Invalid `ack_decoding` config.", %err);
        return None;
    }
};
decoder.parse(request.into_data().into(), Default::default())
Defensive patterns

Strategy: validation

Validate before calling

// validate the client-provided ack config before accepting ACKs
let decoder = ack_config.ack_decoding.build()?; // reject connection on error

Try / catch

match ack_config.ack_decoding.build() { Ok(d) => d, Err(err) => { debug!(%err, "Invalid ack_decoding"); return None; } }

Prevention

When it happens

Trigger: A client connects with an embedded ack configuration whose ack_decoding (codec/charset options) fails DecoderConfig build — e.g. an unsupported codec or invalid combination in the per-client ACK payload config — then sends an ACK request message.

Common situations: WebSocket clients embedding a malformed or unsupported ack_decoding spec in their connection handshake/first message; typo'd codec name in the client's advertised config.

Understand the failure class

Background: "Invalid value" and "allowed values are" config errors: what your library rejected and how to fix it — this error's family across 41 libraries.

Related errors

AI-assisted analysis of vectordotdev/vector@bdb87aeaa4 (2026-09-16). Data as JSON: /api/errors/1b592122e03b8d9b. Report an issue: GitHub.

Appendix: source

Thrown at src/sinks/websocket_server/buffering.rs:253

            ..
        }) = self
            && let Some(log) = event.maybe_as_log_mut()
        {
            let mut buffer = [0; 36];
            let uuid = message_id.hyphenated().encode_lower(&mut buffer);
            log.value_mut()
                .insert(message_id_path, Bytes::copy_from_slice(uuid.as_bytes()));
        }
        message_id
    }

    fn handle_ack_request(&self, request: Message) -> Option<Uuid> {
        let ack_config = self.as_ref().and_then(|mb| mb.client_ack_config.as_ref())?;

        let parsed_message = ack_config
            .ack_decoding
            .build()
            .expect("Invalid `ack_decoding` config.")
            .parse(request.into_data().into(), Default::default())
            .inspect_err(|err| {
                debug!(message = "Parsing ACK request failed.", %err);
            })
            .ok()?;

        let Some(message_id_field) = parsed_message
            .first()?
            .maybe_as_log()?
            .value()
            .get(&ack_config.message_id_path)
        else {
            debug!("Couldn't find message ID in ACK request.");
            return None;
        };

        message_id_field
            .try_bytes_utf8_lossy()

View on GitHub (pinned to bdb87aeaa4)