In a sharded cluster, running a collMod command with both a timeseries granularity change, and another invalid option (e.g. setting a validator over a timeseries collection), over a tracked timeseries collection, for example:

> db.adminCommand({shardcollection: "test.tscoll", key: {m: 1}, timeseries: {timeField: 't', metaField: 'm'}})
> db.runCommand({collMod: "tscoll", timeseries: {granularity: "minutes"}, validator: {x: {$type: "string"}}})
MongoServerError[InvalidOptions]: ...

Fails but only after it has executed midway and created a collection options inconsistency:

The timeseries granularity is updated on the global catalog (config.collections), but not on the local catalog (db.getCollectionInfos()):

> db.getSiblingDB("config").collections.findOne({_id: "test.system.buckets.tscoll"}).timeseriesFields.granularity
minutes
> db.getCollectionInfos({name: "system.buckets.tscoll"})[0].options.timeseries.granularity
seconds
> db.checkMetadataConsistency()
[...] 'CollectionOptionsMismatch' [...]

This happens because the collMod coordinator does not validate the collMod command on its own, but rather relies on the primary shard validating the command during the kUpdateShards phase.

However, this happens after the kUpdateConfig phase, where the granularity is updated on the global catalog.