I had previously missed that kafka-protocol provides a ResponseError type for parsing kafka error codes. This type is super useful, turning the numeric error codes into a meaningful error enum. So this PR:

Uses ResponseError to parse error codes into meaningful error names before including in shotover errors.
Uses ResponseError to avoid writing error codes as magic numbers
Adds error handling for delegation token creation responses which was previously entirely missing (in scram_over_mtls.rs)

PR Walkthrough notes

Some notes on rust features for newstarters reviewing this PR.

Option

rust has a core type in the standard library called Option. It is an enum defined as:

enum Option<T> {
    Some(T),
    None
}

It is similar to java's Optional but a lot better.

In other languages you may set a variable to null to say that no value exists for that variable. However no such functionality exists in rust. Instead we wrap the value in Option to allow for the case where the value does not exist.

For example:

fn print_value(value: Option<i32>) {
    if let Some(value) = value {
        println!("the value is {value}");
    }
}

print_value(Some(10)); // prints: the value is 10
print_value(None); // does not print anything

And this is equivalent:

fn print_value(value: Option<i32>) {
    match value {
        Some(value) => println!("the value is {value}");
        None => {}
    }
}

print_value(Some(10)); // prints: the value is 10
print_value(None); // does not print anything

Result

rust has a core type in the standard library called Option. It is an enum defined as:

enum Result<T, E> {
    Ok(T),
    Err(E)
}

Some languages use exceptions for error handling. Rust does not have exceptions. Some languages use function return values for error handling. Rust does do this, but almost always through the Result type.

fn fallible_operation(value: i32) -> Result<i32, Error> {
    if value == 0 {
        Err(SomethingBad)
    }
    else if value == 1 {
        Err(SomethingTerrible)
    }
    else {
        Ok(value)
    }
}

enum Error {
    SomethingBad,
    SomethingTerrible,
}

// prints: failure SomethingBad
match fallible_operation(0) {
    Ok(value) => println!("success {value}"),
    Err(err) => println!("failure {err:?}"),
}

// prints: failure SomethingTerrible
match fallible_operation(1) {
    Ok(value) => println!("success {value}"),
    Err(err) => println!("failure {err:?}"),
}

// prints: success 3
match fallible_operation(3) {
    Ok(value) => println!("success {value}"),
    Err(err) => println!("failure {err:?}"),
}

anyhow errors

errors that are handled internally should use an enum to represent possible error cases
- example enum definition in shotover: https://github.com/shotover/shotover-proxy/blob/1ea5cb5a1b5bf6052e66cce046ebd427e452b08b/shotover/src/codec/mod.rs#L86-L94
but for user-facing errors we use the anyhow crate to generate errors that explain what went wrong
- https://crates.io/crates/anyhow
- example usage in shotover: https://github.com/shotover/shotover-proxy/blob/48d70afcb16c1f431e93e68fd24a0da1be3f5f92/shotover/src/transforms/kafka/sink_cluster/mod.rs#L1076-L1078
- e.g. these sequence of errors that we saw before are kept track of by anyhow https://github.com/shotover/shotover-proxy/blob/1ea5cb5a1b5bf6052e66cce046ebd427e452b08b/shotover-proxy/tests/redis_int_tests/mod.rs#L70-L76

shotover / shotover-proxy

Improve KafkaSinkCluster server error handling #1625

PR Walkthrough notes

Option

Result

anyhow errors

CodSpeed Performance Report

Merging #1625 will not alter performance

Summary