-
Notifications
You must be signed in to change notification settings - Fork 21
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
Hide forecasted grants while UI is being developed to support forecasted grants #3456
base: main
Are you sure you want to change the base?
Conversation
QA Summary
Test CoverageCoverage report for `packages/client`
Coverage report for `packages/server`
|
Terraform Summary
Hint: If "Terraform Format & Style" failed, run OutputValidation Output
Plan Summary
Pusher: @lsr-explore, Action: |
6a50a35
to
4ca864b
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.
@masimons Confirming that the direction this is headed makes sense to me 👍
I'll mention that I think it could be useful to have an environment variable control the exclusion of forecasted grants. Due to how we ship and run Docker images, it's not something that we could toggle in a Staging/Prod environment without re-deploying, but 1) it might be helpful for development purposes, and 2) might make it easier to activate once we get to the point where we want to start including forecasted grants in one or both of those environments.
4ca864b
to
32a4bc3
Compare
@TylerHendrickson thanks for checking this out, I missed this comment. Out of curiosity, do you have an example off the top of your head where we use an env var in that way? I was looking into how we use feature flags, but it seems that those are scoped to the client side? |
@masimons re
The implementation details for #3060 provide some instructions for implementing an API-side feature flag using a Fundamentally, this sort of thing would entail the following:
I'd recommend that an environment variable that provides a binary feature flag be evaluated as a string using strict equality, e.g. |
15e2749
to
e0b63ab
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.
@masimons I really like how this implementation parameterizes the flag in src/db/index.js
and allows the caller to decide whether to pull in the toggle from env var or something else. This is looking good overall!
I did notice in local testing that setting SHOW_FORECASTED_GRANTS=false
in packages/server/.env
doesn't seem to have the desired effect (I could still see forecasted grants in search results), although when the env var is altogether missing, forecasted grants are hidden like we'd expect.
I believe this is because the packages/server/db/index.js
functions are expecting a true boolean value (or else undefined
, so that the arg default of false
in the function signature is used), but when a value is provided from process.env.SHOW_FORECASTED_GRANTS
, it's a string rather than a boolean, and !"false"
is evaluating to true
. I think the simplest way to resolve this is to have callers explicitly check whether process.env.SHOW_FORECASTED_GRANTS === "true"
, which I provided in a comment suggestion.
029057a
to
321c973
Compare
@TylerHendrickson , @masimons - I've accepted Ty's changes - this should be ready for review |
321c973
to
6b1e358
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.
@lsr-explore Thanks for the updates. I think we need the strict === 'true'
comparison for all usages of the environment variable, so I added a few additional comment suggestions to address those as well. I think that I covered all of them, but feel free to double check me on that 🙂
34fa36a
to
2ca7c64
Compare
fe6cfc3
to
935ca69
Compare
…le in a couple othr places
Sorry that I missed this @TylerHendrickson . I applied the changes and did another sanity check of the code. I noticed a couple additional places where the flag needed to be sent and added a commit. I noticed that the db.getGrantsInterested didn't have this check. This would only be an issue if we needed to turn off grants after enabling it and user had clicked follow. Do you think we need the check on getGrantsInterested? |
That's a fair point - I don't know if that particular case came up when we were thinking about this |
Ticket #3213
Description
Hide forecasted grants on production during development and testing.
Screenshots / Demo Video
Testing
Automated and Unit Tests
Manual tests for Reviewer
Checklist