In the causal consistency secondary read preference suite, there are a few workloads that sometimes timeout. Currently they are blacklisted, but their causes should be investigated so the tests can be re-enabled.

The known workloads are:

• update_multifield_isolated_multiupdate_noindex.js: https://evergreen.mongodb.com/task/mongodb_mongo_master_ubuntu1604_debug_ubsan_concurrency_sharded_causal_consistency_WT_patch_a644bf58213f0786b8415277c1d54277b4f14581_59b04453e3c33147710011de_17_09_06_18_57_25/2

• update_multifield_isolated_multiupdate.js: https://evergreen.mongodb.com/task/mongodb_mongo_master_windows_64_2k8_debug_concurrency_sharded_causal_consistency_and_balancer_WT_patch_2197cedd9cc61cba6ceb81affc348d3e3932c1b8_59b2c33be3c33179c0000bf5_17_09_08_16_21_16/1

• update_multifield_multiupdate.js (w/o hang analyzer output): https://evergreen.mongodb.com/task/mongodb_mongo_master_ubuntu1604_debug_asan_concurrency_sharded_causal_consistency_and_balancer_WT_patch_978521eb3926867b30903781fd89d4acd931f0c4_59b839f8e3c331235900eaf9_17_09_12_19_54_19/0

• update_multifield_multiupdate_noindex.js

• yield_id_hack.js - https://evergreen.mongodb.com/task/mongodb_mongo_master_windows_64_2k8_debug_concurrency_sharded_causal_consistency_WT_patch_2197cedd9cc61cba6ceb81affc348d3e3932c1b8_59b2c33be3c33179c0000bf5_17_09_08_16_21_16/1

• indexed_insert_text_multikey.js - https://evergreen.mongodb.com/task/mongodb_mongo_master_enterprise_rhel_62_64_bit_coverage_concurrency_sharded_causal_consistency_patch_2197cedd9cc61cba6ceb81affc348d3e3932c1b8_59b2c33be3c33179c0000bf5_17_09_08_16_21_16/4

• indexed_insert_multikey.js

• indexed_insert_multikey_noindex.js

*note
For some of the failures, the fsm log output claims that the hung workload "completed" in roughly 6 hours, but this is misleading because if the test registers as timed out, attaching GDB to the hung process can cause the others to break out of their hang long enough for the workload to continue for a short period of time (possibly by changing their perception of that node to "down" instead of whatever was causing the hang). So even though some logs may claim the hung workload eventually completed, it's very likely it did not.