mirror of
https://github.com/facebook/sapling.git
synced 2024-10-11 01:07:15 +03:00
c60fcebc12
Summary: `ObservabilityContext` is a structure that helps logging facilities within Mononoke to make logging decisions. Specifically, the upcoming `DynamicLoggingDrain` and already existing `MononokeScubaSampleBuilder` will have this structure as a component and decide whether a particular logging statement (slog or scuba) should go ahead. Internally, `ObservabilityContext` is a wrapper around data received from a [configerator endpoint](https://www.internalfb.com/intern/configerator/edit/?path=scm%2Fmononoke%2Fobservability%2Fobservability_config.cconf). This diff makes a few unobvious decisions about how this is organized. My goals were: 1. to have production (i.e. reading from configerator), static (i.e. emulating current prod behavior) and test variants of `ObservabilityContext` 1. to avoid having consumers know which of these variants are used 1. to avoid making all consumers of `ObservabilityContext` necessarily generic 1. to avoid using dynamic dispatch of `ObservabilityContext`'s methods Points 3 and 4 mean that `ObservabilityContext` cannot be a trait. `enum` is a common solution in such cases. However, if `ObservabilityContext` is an `enum`, consumers will know which variant they are using (because `enum` variants are public). So the solution is to use a private enum wrapped in a struct. Reviewed By: mitrandir77 Differential Revision: D25287759 fbshipit-source-id: da034c71570137e8a8fb7749b1e4ad43be482f66 |
||
|---|---|---|
| .. | ||
| fs | ||
| integration | ||
| locale | ||
| mononoke | ||
| scm | ||
| test_support | ||
| test-data | ||
| .gitignore | ||
| Eden.project.toml | ||