-X args with security properties panics

[xianwill]

On macOS, I have a couple of configurations for consuming from Kafka w/ TLS that work with kafkacat but panic w/ kafkakitty. To keep the explanation simple and direct, I'll describe the pem-encoded cert configuration and leave jks out of it.

After setting up these environment variables

• KAFKA_DEV_BROKER
• KAFKA_DEV_CERT
• KAFKA_DEV_KEY

I can successfully launch a TLS kafkacat consumer with

kafkacat -C \
	-b $KAFKA_DEV_BROKER \
	-t provisioning_test-acl_restricted \
	-X security.protocol=SSL \
	-X ssl.certificate.location=$KAFKA_DEV_CERT \
	-X ssl.key.location=$KAFKA_DEV_KEY

Using the same args w/ kafkakitty like so

target/debug/kafkakitty 	\
        -b $KAFKA_DEV_BROKER \
	-t provisioning_test-acl_restricted \
	-X security.protocol=SSL \
	-X ssl.certificate.location=$KAFKA_DEV_CERT \
	-X ssl.key.location=$KAFKA_DEV_KEY

results in:

thread '<unnamed>' panicked at 'Consumer createion failed: KafkaError (Client config error: No such configuration property: "ssl.key.location" ssl.key.location terraform.key)', src/libcore/result.rs:1189:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace.
...

kafkakitty terminates after the panic.

Running with RUST_BACKTRACE=1 gives this stacktrace:

   0: std::sys_common::at_exit_imp::push
   1: core::fmt::ArgumentV1::show_usize
   2: std::io::Write::write_fmt
   3: std::panicking::default_hook::{{closure}}
   4: std::panicking::default_hook
   5: <std::panicking::begin_panic::PanicPayload<A> as core::panic::BoxMeUp>::get
   6: std::panicking::continue_panic_fmt
   7: std::panicking::try::do_call
   8: std::panicking::begin_panic
   9: std::panicking::begin_panic
  10: core::result::Result<T,E>::expect
             at /rustc/412f43ac5b4ae8c3599e71c6972112e9be4758fa/src/libcore/result.rs:984
  11: kafkakitty::kafka::consume
             at src/kafka.rs:39
  12: kafkakitty::main::{{closure}}
             at src/main.rs:147
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

[rtyler]

@xianwill I am unable to reproduce this error, which has me wondering whether the environment variables in your example contain any non-ASCII characters?

Perhaps run with RUST_BACKTRACE=1 set in your environment, that will give the full stacktrace

[xianwill]

Something is different today, could be on my side. tl;dr is, the application panics and then terminates with a pretty clear error message now:

No such configuration property: "ssl.certificate.location"

I ran with RUST_BACKTRACE=1 and updated the bug description with the new behavior and stacktrace.