[SOLR-16751] ClusterState.collectionFromObjects() stores copy of shards in DocCollection.getProperties()

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Fix Version/s: main (10.0), 9.3
• Assignee: Chris M. Hostetter
• Reporter: Chris M. Hostetter
• Created: 18/Apr/23 00:22
• Updated: 21/Jul/23 20:40
• Resolved: 18/Apr/23 18:33

Description

The way a DocCollection is created by ClusterState.collectionFromObjects() ( ie: ClusterState is read from a JSON payload – such as state.json ) a copy of the original "shards" mappings is left in the props argument (where it's carried around in DocCollection.getProperties() ) in addition to the (correct) slices argument (which is used to build DocCollection.getSlices() )

This is due to the following lines of code, which AFAICT should have been done in reverse order...

      props = new HashMap<>(objs);
      objs.remove(CollectionStateProps.SHARDS);

This bug seems to have existed for a while, but seems to have slipped under the radar since nothing has any reason to be looking for a "shards" key in DocCollection.getProperties() .

Recently however, noble committed 2ac7ed29563a33d9f9a31737996a1d4cfb0fca0d which changed the serialization logic for DocCollection to eliminate a temporary map...

-    LinkedHashMap<String, Object> all = CollectionUtil.newLinkedHashMap(slices.size() + 1);
-    all.putAll(propMap);
-    all.put(CollectionStateProps.SHARDS, slices);
-    jsonWriter.write(all);
+    jsonWriter.write(
+        (MapWriter)
+            ew -> {
+              propMap.forEach(ew.getBiConsumer());
+              ew.put(CollectionStateProps.SHARDS, slices);
+            });

... so now, instead of an all Map where the "shards" key from propMap being (correctly) overridden by slices and then serialized, now the JSON output contains two entries with the "shards" key.

Issue Links

• causes: SOLR-16891 Solr Cloud Graph screen blank
• relates to: SOLR-16753 SplitShardWithNodeRoleTest.testSolrClusterWithNodeRoleWithPull failures