-
Notifications
You must be signed in to change notification settings - Fork 16
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
[Issue #2695] opportunity and search toggle with feature flag env vars #3115
Conversation
be196a6
to
9f4febc
Compare
get featureFlags(): FeatureFlags { | ||
return { | ||
...this.defaultFeatureFlags, | ||
...this.featureFlagsFromEnvironment, |
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.
note that this means that if a user in any way sets their cookie to override the flag, they'll be able to access search or opportunities
if (!this.isValidFeatureFlag(featureName)) { | ||
throw new Error(`\`${featureName}\` is not a valid feature flag`); | ||
} | ||
const featureFlags = { | ||
...this.featureFlags, | ||
...this.featureFlagsCookie, |
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 a change to the existing functionality - previously whenever we set the feature flags cookie it would enshrine the default feature flag values in the cookie, but that functionality conflicts with idea of honoring flags set in the environment and using cookies as an override. Setting a flag on the cookie should, in this case, only set the single flag value specified
frontend/package.json
Outdated
@@ -8,7 +8,7 @@ | |||
"scripts": { | |||
"all-checks": "npm run test && npm run lint && npm run ts:check && npm run build", | |||
"build": "next build", | |||
"dev": "next dev", | |||
"dev": "NEW_RELIC_ENABLED=false next dev", |
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.
unrelated but makes local development logs less busy
export const revalidate = 600; // invalidate ten minutes | ||
export const dynamic = "force-dynamic"; |
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 honestly don't understand why this needs to be here since we are already including the generateStaticParams, but without the the production build fails to render the page due to the dependence on searchParams in the withFeatureFlag code
// This should be removed when the search page goes live, before May 2024 | ||
showSearchV0: true, | ||
hideSearchV0: false, |
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.
do we still need this? I changed it to a hide
vs show
variable to match the pattern here and allow us to more easily reason about feature flag effects
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 think we could drop this at this point. Or we could try to generalize it as like searchBeta that we can keep rolling things out using and then remove the flag checks as we consider those things Released.
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 would remove it. When I turned it on locally it created a 500 error or the search page.
db3d154
to
ddddffa
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.
Looks good.
// This should be removed when the search page goes live, before May 2024 | ||
showSearchV0: true, | ||
hideSearchV0: false, |
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 think we could drop this at this point. Or we could try to generalize it as like searchBeta that we can keep rolling things out using and then remove the flag checks as we consider those things Released.
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.
Tested locally, looks great.
ddddffa
to
14c5623
Compare
14c5623
to
ce959ae
Compare
Summary
Fixes #2695
Time to review: 30 mins
Changes proposed
The goal of the PR is the addition of two "kill switch" parameters that can be used to direct the search and opportunity pages, respectively, to a maintenance page. These parameters can be supplied either on the frontend via query params or feature flags admin panel, or via environment variables.
Setting flags via environment variables is a new functionality, so changes were made to the system to get this to work. Some deficiencies of the existing system were also patched up as part of this process.
Context for reviewers
Test Steps
FEATURE_OPPORTUNITY_OFF=true FEATURE_SEARCH_OFF=true npm run dev
on this branchnpm run build && FEATURE_OPPORTUNITY_OFF=true FEATURE_SEARCH_OFF=true npm start
Dockerized
I would like to be able to test the changes to the Dockerfile locally, but can't without creating a docker compose that runs the production Next build and start rather than
next dev
. I feel like that's out of scope for this change, so we should just deploy out to DEV and test there.Additional information