ref(utils): Various clarifications in SafeRolloutComparator code#115946
Conversation
96d8e03 to
eb960be
Compare
| 3. Start rolling out the "evaluate experimental branch" option. | ||
| 4. Monitor correctness through standard dashboard. (TODO @cpaul: build dashboard) | ||
| 5. Start adding known-good callsites to the "use experimental branch" allowlist. | ||
| 1. Set up your `SafeRolloutComparator` subclass (in Sentry) & options (in options automator). |
There was a problem hiding this comment.
How do we handle referencing internal repos (like options automator) in open-source repos?
| 4. Monitor correctness through standard dashboard. (TODO @cpaul: build dashboard) | ||
| 5. Start adding known-good callsites to the "use experimental branch" allowlist. | ||
| 1. Set up your `SafeRolloutComparator` subclass (in Sentry) & options (in options automator). | ||
| 2. Add code like that below your first callsite. (Further callsites can be added at any time.) |
There was a problem hiding this comment.
"Add code like that" — what does this mean?
There was a problem hiding this comment.
Meant to be "code like that [that you can find] below," but I get how it can be read ambiguously. Changed to Use the comparator in your first callsite (see example below)..
| 1. Set up your `SafeRolloutComparator` subclass (in Sentry) & options (in options automator). | ||
| 2. Add code like that below your first callsite. (Further callsites can be added at any time.) | ||
| 3. Start rolling out the experiment by switching the "should run experiment" option to True | ||
| and increasing the sample rate option. |
There was a problem hiding this comment.
"increasing" is wrong here — default sample rate is 1.0 ==> 100%, so folks can OPTIONALLY set the sample rate option but don't have to.
There was a problem hiding this comment.
Ah, right. Good catch. Changed to Start rolling out the experiment by switching the "should run experiment" option to True and, if you've set a sample rate option, increasing the sample rate. (If not set, the sample rate defaults to 100%.)
| and increasing the sample rate option. | ||
| 4. Monitor correctness using the metrics and optional mismatch logs emitted when the | ||
| experimental branch is run. | ||
| 5. Start adding known-good callsites to the "use new data" allowlist. |
There was a problem hiding this comment.
The method is called should_use_experimental_data but the allowlist uses new — IMO we should unify on experimental vs new.
There was a problem hiding this comment.
Used new for length reasons, but can switch it back to experimental.
| use_experimental_data: bool, | ||
| is_exact_match: bool, | ||
| is_reasonable_match: bool | None, | ||
| is_experimental_data_nullish: bool | None, |
There was a problem hiding this comment.
Nit: I'd keep as null_result to keep consistency with what we're sending to DataDog.
There was a problem hiding this comment.
I left all of the DD and logging labels alone so as not to break existing dashboards, etc, but I like "nullish" because is sort of the equivalent of "falsy" - an empty list isn't the same as an actual None, for example, the same way an empty string isn't the same as False.
| experimental_data: TData, | ||
| callsite: str, | ||
| is_experimental_data_a_null_result: bool | None = None, | ||
| is_experimental_data_nullish: bool | None = None, |
There was a problem hiding this comment.
See above re: nullish
| control_data_func: Callable[[], TData], | ||
| experimental_data_func: Callable[[], TData], |
There was a problem hiding this comment.
Nit: I like thunk. Will let you choose though.
There was a problem hiding this comment.
It's a neat word, just not sure how widely understood it's going to be.
…allowlist_option`
…log_allowlist_option`
eb960be to
2f4f867
Compare
This makes some clarifying changes to the
SafeRolloutComparatorutility, based on my experience getting oriented to using it. No behavioral changes.