scylla-rust-driver icon indicating copy to clipboard operation
scylla-rust-driver copied to clipboard

Unwrap panic when using `execute_iter` concurrently

Open tqwewe opened this issue 1 year ago • 3 comments

When using execute_iter concurrently in tokio::spawns, I sometimes encounter an unwrap panic from Scylla. The unwrap causing the panic is in the new_from_worker_future function here: https://github.com/scylladb/scylla-rust-driver/blob/99330c8531392c24478e33a5a576780e25680aa1/scylla/src/transport/iterator.rs#L402-L407

A reproduction can be found here: https://github.com/thalo-rs/thalo/tree/scylladb-event-store in branch scylladb-event-store at commit 7946eed5593cd07e4d6c58601e9351766b41e38c

You'll need to build the counter.wasm module using thalo_cli, and then run cargo r -p thalo_runtime.

image

tqwewe avatar Dec 17 '23 05:12 tqwewe

Oh I realize its because I spawn the tasks but immediately exit my main function without waiting for them to complete, which I guess breaks the This unwrap is safe because: That future is polled in a tokio::task which isn't going to be cancelled assumption.

I guess one solution might be to do:

let pages_received = receiver.recv().await.unwrap_or_else(|| Err(QueryError::...))?;

Alternatively this can also be ignored since it only panics if the tokio runtime exits.

tqwewe avatar Dec 17 '23 05:12 tqwewe

This is actually the second time this issue is reported (https://github.com/scylladb/scylla-rust-driver/issues/615). I think we shouldn't close it until we improve the panic message or return a proper error instead of panicking.

piodul avatar Jan 08 '24 10:01 piodul

I suggest resolving this by calling expect("The future returned by worker.work was cancelled instead of performing graceful shutdown") instead of unwrapping.

wprzytula avatar Apr 08 '24 11:04 wprzytula