The full error is:

ReqlInternalError("Unexpected exception: The attempt to read or "
    "modify the table's configuration failed because none of the "
    "servers were accessible.  If it was an attempt to modify, the "
    "modification did not take place.")

The source of this is a failed_table_op_exc_t, but contrary to the error text, the cluster was fully available during this time, and no disconnections were seen in the logs. A ReqlInternalError should not be returned to users during normal operation, so either the error needs to be changed or we need more error handling somewhere. This exception can be thrown from 5 places:

clustering/administration/tables/generate_config.cc:290 - table_generate_config(...) when generating a config for a table that shows as disconnected through the table_meta_client_t.

clustering/administration/tables/split_points.cc:109 - fetch_distribution(...) when the distribution_read_t throws a cannot_perform_query_exc_t, but the table_meta_client_t does not indicate that the table has been deleted.

clustering/table_manager/table_meta_client.cc:561 - create_or_emergency_repair(...) when no business cards could be found for any of the servers involved with the new config for the table

clustering/table_manager/table_meta_client.cc:772 - retry(...) just rethrows failed_table_op_exc_t after all attempts failed, ignore this one.

clustering/table_manager/table_meta_client.cc:789 - throw_appropriate_exception(...), which is used in several places to throw a failed_table_op_exc_t if the table is known to exist, and a no_such_table_exc_t otherwise. Mostly after a get_status call fails, and once in set_config if no leader can be found for the table being changed.