-
Notifications
You must be signed in to change notification settings - Fork 31
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
Use user benefits abtest #13137
Use user benefits abtest #13137
Conversation
Hello 👋! When you're ready to run Chromatic, please apply the You will need to reapply the label each time you want to run Chromatic. |
Size Change: +231 B (+0.03%) Total Size: 884 kB
ℹ️ View Unchanged
|
}, | ||
); | ||
if (!validateResponse(response)) { | ||
throw new Error('invalid response'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
presumably that will throw an alarm somewhere for us/sentry?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess? Not sure, this is the same as the previous implementation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
true I guess the more pertinent question is how will you know that everything is working with the new API like it was before across a similar percentage of browsers
36dece9
to
c6c44a0
Compare
c6c44a0
to
65ecce9
Compare
d5cd1f1
to
8263a51
Compare
2de412d
to
549714f
Compare
return Promise.reject('The user is not signed in'); | ||
} | ||
if (shouldUseUserBenefitsApi()) { | ||
return syncDataFromUserBenefitsApi(authStatus).then(persistResponse); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is neat that both methods return value of the same shape (so can use persistResponse
in both cases).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM! 👍
): Promise<UserBenefits> => { | ||
const response = await fetchJson( | ||
window.guardian.config.page.userBenefitsApiUrl ?? | ||
'/USER_BENEFIT_API_NOT_FOUND', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it be clearer/more explicit to error in the case that the url isn't set in config? (Rather than making a request to a non-existent URL?)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did think that as well, but I stuck with the way it was written already. Happy to change it, what do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I went ahead and changed it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah great, yeah I think it feels like there'd be less scope for confusion when debugging an issue that way 👍
The screenshots in the descrtiption appear as broken images for me. Out of interest wouldn't this have been ok as a client side "AB test" (which would presumably avoid splitting the cache?) |
c2ec95d
to
9709c95
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nice work 👏
The test needs to be used too early in the page load for a client side test because they rely on React being available. |
Seen on PROD (merged by @rupertbates 7 minutes and 47 seconds ago) Please check your changes! |
What does this change?
Adds the new user-benefits api as a source of information about what benefits (ad-free, hide support messaging) a user is entitled to.
The switch over to the new API is going to be managed with an server side AB test to allow us to control the amount of traffic going to the new service.
This PR requires support-service-lambdas to handles CORS