Not every collection has a UUID even when the server is in featureCompatibilityVersion=3.6. For example, as part of SERVER-30500, the "system.indexes" collection on a database won't have a UUID. This means that calls to Collection::uuid() in DbCheckJob::_getCollectionMetadata() may attempt to get the value from an uninitialized boost::optional, leading to a segmentation fault.
auto collection = agd.getDb()->getCollection(opCtx, info.nss); if (!collection) { return false; } auto prev = UUIDCatalog::get(opCtx).prev(_dbName, *collection->uuid()); auto next = UUIDCatalog::get(opCtx).next(_dbName, *collection->uuid());
Note: Due to how updateUUIDSchemaVersion() is only called with upgrade=true when the "setFeatureCompatibilityVersion" version command is run, if we manually modify the featureCompatibilityVersion document, then we can make a scenario where the server wouldn't have UUIDs for its collections while still being in featureCompatibilityVersion=3.6 even when running with the WiredTiger storage engine.