-
Notifications
You must be signed in to change notification settings - Fork 142
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
probeservices: A/B testing using check-in API feature flags #2396
Labels
enhancement
improving existing code or new feature
funder/drl2022-2024
ooni/probe-engine
priority/high
research prototype
testing
Comments
9 tasks
bassosimone
changed the title
webconnectivity: use the check-in API to conditionally enable LTE
probeservices: A/B testing using check-in API feature flags
Jan 12, 2023
This was referenced Jan 12, 2023
bassosimone
added
enhancement
improving existing code or new feature
testing
priority/high
research prototype
ooni/probe-engine
funder/drl2022-2024
and removed
triage
labels
Jan 12, 2023
bassosimone
added a commit
to ooni/probe-cli
that referenced
this issue
Jan 17, 2023
Specifically, name it ...ResultNettests such that it's clear by inspection that this structure belongs to the results. Part of ooni/probe#2396
bassosimone
added a commit
to ooni/probe-cli
that referenced
this issue
Jan 17, 2023
Specifically, name it ...ResultNettests such that it's clear by inspection that this structure belongs to the results. Part of ooni/probe#2396
bassosimone
added a commit
to ooni/probe-cli
that referenced
this issue
Jan 17, 2023
This diff refactors engine/session.go such that the session code can observe the full check-in response. We're still returning the nettests subset to the caller, since normally callers only care about that. By observing the full response, we'll be able to cache the feature flags, which will then be useful to implement ooni/probe#2396.
bassosimone
added a commit
to ooni/probe-cli
that referenced
this issue
Jan 17, 2023
While working on ooni/probe#2396, I noticed that the httpapi code could return nil, nil when the input from the server was the `null` UTF-8 string. In such a case, golang translates the `null` string into a `nil` pointer. However, if we pass the pointer to a struct rather than the pointer to a pointer, the code returns an empty struct, which is much safer. This reasoning works as long as we assume the caller wants to get a struct by pointer or nil on error. If the caller for some reason wants the code to return a `**T` type, we're back in the case where the code can return `nil`, `nil`. But all our code always wants a `*T` back and this seems the only case that makes sense.
bassosimone
added a commit
to ooni/probe-cli
that referenced
this issue
Jan 17, 2023
While working on ooni/probe#2396, I noticed that the httpapi code could return nil, nil when the input from the server was the `null` UTF-8 string. In such a case, golang translates the `null` string into a `nil` pointer. However, if we pass the pointer to a struct rather than the pointer to a pointer, the code returns an empty struct, which is much safer. This reasoning works as long as we assume the caller wants to get a struct by pointer or nil on error. If the caller for some reason wants the code to return a `**T` type, we're back in the case where the code can return `nil`, `nil`. But all our code always wants a `*T` back and this seems the only case that makes sense.
bassosimone
added a commit
to ooni/probe-cli
that referenced
this issue
Jan 17, 2023
bassosimone
added a commit
to ooni/probe-cli
that referenced
this issue
Jan 17, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
enhancement
improving existing code or new feature
funder/drl2022-2024
ooni/probe-engine
priority/high
research prototype
testing
This issue is about adding to the check-in API support for A/B testing. Our guinea pig will be [email protected] but our aim will be more general. We will want to have support for choosing different implementations of experiments or to enable extra features hidden by feature flags. In turn, this will give us a better ecosystem for moving forward our goals of providing more structured input for OONI experiments. In particular, we will be able to test new extra functionality with a subset of clients, thus allowing us to move faster. It's also worth mentioning that this functionality will be useful to start testing the throttling measurement functionality we plan on adding to Web Connectivity (see ooni/ooni.org#1296).
Part of #2237 and #2362
The text was updated successfully, but these errors were encountered: