-
Type:
Task
-
Resolution: Fixed
-
Priority:
Major - P3
-
Affects Version/s: None
-
Component/s: manual
-
Labels:
Description
Downstream Change Summary
- Introduces new optional "provenance" field for readConcern and writeConcern objects.
- Clients do not have to set this field, and we recommend that they avoid doing so. If they do include the field, it can only be with the value "clientSupplied". This is mostly for clients using runCommand directly; drivers do not support this field natively in their read/write concern support (and will not, since for clients there is only one valid value and its absence (the current behaviour) has the same meaning).
- The provenance value provides diagnostic information about where the read or write concern originated. Users may observe this field in logs, profiling, and other places where read/write concern objects are recorded. Possible values for this origin are:
- "clientSupplied" : in the application/driver.
- "customDefault" : in the server from a custom defined default read/write concern (set with the setDefaultRWConcern command).
- "getLastErrorDefaults" (only for write concern) : in the server from the (now deprecated) settings.getLastErrorDefaults field in a replica set configuration.
- "implicitDefault" : the read/write concern is that used by the server in the absence of all the above alternative sources.
- WriteConcernErrors now include the causal writeConcern as the new "errInfo.writeConcern" field.
- This is necessary because, in the presence of a custom default write concern (or getLastErrorDefaults), it is possible to receive a WriteConcernError on an operation that did not supply an explicit writeConcern.
- The "errInfo.writeConcern" includes the above "provenance" field, to additionally help determine why the write concern was applied to the operation.
- It is believed that drivers should not currently be attempting to parse "errInfo", but it would be good to add the necessary test coverage and/or spec definitions.
- Drivers should ensure that the contents of the "errInfo" object are propagated up to the application-visible error/exception, so that developers/admins can be aware of situations such as custom write concern defaults causing wtimeouts, etc.
- New serverStatus metrics (including in FTDC):
- "getLastError.default.wtimeouts" : Number of times a non-"clientSupplied" write concern timed out (ie. wtimeouts caused by an "implicitDefault", "customDefault", or "getLastErrorDefaults" write concern). Note that the existing "getLastError.wtimeouts" metric is also still incremented in this case.
- "getLastError.default.unsatisfiable" : Number of times that a non-"clientSupplied" write concern was unsatisfiable (ie. returned the UnsatisfiableWriteConcern error code).
Description of Linked Ticket
Add and propagate provenance info to readConcern and writeConcern, to help with tracing where a given RWC has come from. This is especially useful when default RWC causes operations to fail (perhaps because the default RWC may be unsatisfiable).
Scope of changes
Impact to Other Docs
MVP (Work and Date)
Resources (Scope or Design Docs, Invision, etc.)
- documents
-
SERVER-45623 RWC provenance
-
- Closed
-