From f03df56844ffa590a45af51403ee929068b72ec5 Mon Sep 17 00:00:00 2001
From: Seebs <seebs@molecula.com>
Date: Wed, 24 Aug 2022 17:32:33 -0500
Subject: [PATCH] avoid insanely strange crash

So, nShards used to be 10. If you run a complete test, with go
test -race, and you have the sample input for the unrelated
TestImportMutexSampleData configured to use 64K bit density and 2K
rows, everything is fine. If you run a partial test, everything is
fine. If you run a complete test with -race, but you skip
TestImportMutexSampleData, or reduce either the bit density or the
row count, you get a very strange panic where the go panic handler
panics trying to report what happened so we don't get a valid stack
dump. On Macs. This is as much as I could debug it after about 6
hours. Since there's no special reason to think we need all 10
shards, and 9 still tests the behavior, we're leaving this one a
mystery.
---
 api_test.go               | 17 +++++++++++++++--
 fragment_internal_test.go |  4 ++--
 2 files changed, 17 insertions(+), 4 deletions(-)

diff --git a/api_test.go b/api_test.go
index d39a7c3b1..43577ddac 100644
--- a/api_test.go
+++ b/api_test.go
@@ -1126,7 +1126,7 @@ func TestAPI_MutexCheck(t *testing.T) {
 	rowKeysBase := []string{"v0", "v1", "v2", "v3"}
 	colKeysBase := []string{"c0", "c1", "c2", "c3"}
 
-	const nShards = 10
+	const nShards = 9
 
 	// now, try the same thing for each combination of keyed/unkeyed. we
 	// share code between keyed/unkeyed fields, but for indexes, the logic
@@ -1191,7 +1191,20 @@ func TestAPI_MutexCheck(t *testing.T) {
 				(4 << shardwidth.Exponent) + 1: true,
 				(5 << shardwidth.Exponent) + 1: true,
 				(8 << shardwidth.Exponent) + 1: true,
-				(9 << shardwidth.Exponent) + 1: true,
+				// So, nShards used to be 10. If you run a complete test,
+				// with go test -race, and you have the sample input for the
+				// unrelated TestImportMutexSampleData configured to use 64K
+				// bit density and 2K rows, everything is fine. If you run a
+				// partial test, everything is fine. If you run a complete
+				// test with -race, but you skip TestImportMutexSampleData,
+				// or reduce either the bit density or the row count, you get
+				// a very strange panic where the go panic handler panics
+				// trying to report what happened so we don't get a valid
+				// stack dump. On Macs. This is as much as I could debug it
+				// after about 6 hours. Since there's no special reason to
+				// think we need all 10 shards, and 9 still tests the
+				// behavior, we're leaving this one a mystery.
+				// (9 << shardwidth.Exponent) + 1: true,
 			}
 
 			results, err := m0.API.MutexCheck(ctx, qcx, indexData.indexName, fieldData.fieldName, true, 0)
diff --git a/fragment_internal_test.go b/fragment_internal_test.go
index ab7acb1c8..ed3307a76 100644
--- a/fragment_internal_test.go
+++ b/fragment_internal_test.go
@@ -4811,8 +4811,8 @@ type mutexSize struct {
 var mutexDensities = []mutexDensity{
 	// {"64K", 16},
 	// {"32K", 15}, // 50-50
-	{"16K", 14}, // 1/4
-	// {"8K", 13},
+	//{"16K", 14}, // 1/4
+	{"8K", 13},
 	// {"4K", 12}, // a fair number of things
 	{"1K", 10},
 	// {"1", 0},   // about one per container