Bogdan Kanivets

> It seems that the etcd data directories will never be removed? What will happen if we restart the functional test when it fails? This line in test.sh will remove...

[PR](https://github.com/etcd-io/etcd/pull/14149) isn't merged yet, but even if solution changes, I think test is relevant

Sorry about delay. Will update soon.

@ahrtr @ptabor FYI, this is ready to merge

Here are some more examples of failure due to ETCD_TESTER_EXIT_CODE: 2 https://github.com/etcd-io/etcd/runs/7528996274?check_suite_focus=true https://github.com/etcd-io/etcd/runs/7443519017?check_suite_focus=true https://github.com/etcd-io/etcd/runs/7436236229?check_suite_focus=true

if nobody is looking at this, please assign to me

still looking at this issue. Quick update. There are couple separate investigations: 1. Two runs failed due to {"level":"warn","ts":1658383863.827886,"caller":"tester/cluster_run.go:50","msg":"round FAIL","round":0,"case":2,"case-total":22,"error":"injection error: cluster too slow: only 1961 commits in 6 retries"}...

Let close this issue. ### Quick summary 1. no solution for BLACKHOLE_PEER_PORT_TX_RX_LEADER_UNTIL_TRIGGER_SNAPSHOT (see note below). 2. seams to be a one-off 3. Filed https://github.com/etcd-io/etcd/issues/14384 ### BLACKHOLE_PEER_PORT_TX_RX_LEADER_UNTIL_TRIGGER_SNAPSHOT On my local Mac...

For ref, here is original commit that added `commitTo` with `panic` https://github.com/etcd-io/etcd/pull/1740

I think this is a good catch and a relevant bug. TLTR: etcd transaction shouldn't panic based on client context errors (timeouts, cancelations) Here is how this happened: 1. Etcd...