Skip to content
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

feat: Block access after seven days notice of API overage #3714

Merged
merged 11 commits into from
May 7, 2024

Conversation

zachaysan
Copy link
Contributor

Thanks for submitting a PR! Please check the boxes below:

  • I have run pre-commit to check linting
  • I have added information to docs/ if required so people know about the feature!
  • I have filled in the "Changes" section below?
  • I have filled in the "How did you test this code" section below?
  • I have used a Conventional Commit title for this Pull Request

Changes

Building upon my previous PR which itself builds upon the use of API usage notification models this PR provides the following improvements:

  • Setting two variables, stop_serving_flags and block_access_to_admin, to True for organisations that have received an API usage warning at least 7 days old. This only applies to free accounts as paid accounts are going to be automatically charged in a subsequent PR.
  • Automatically undoing the above states in cases where an organisation's subscription plan is changed to something new.
  • Automatically undoing the above states when an API usage notification about the 100% threshold has not been filed within the past month.

How did you test this code?

Two large tests and a decent amount of time with a debugger.

@zachaysan zachaysan requested a review from matthewelwell April 3, 2024 18:25
Copy link

vercel bot commented Apr 3, 2024

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name Status Preview Comments Updated (UTC)
docs ✅ Ready (Inspect) Visit Preview 💬 Add feedback May 3, 2024 3:50pm
flagsmith-frontend-preview ✅ Ready (Inspect) Visit Preview 💬 Add feedback May 3, 2024 3:50pm
flagsmith-frontend-staging ✅ Ready (Inspect) Visit Preview 💬 Add feedback May 3, 2024 3:50pm

@github-actions github-actions bot added the api Issue related to the REST API label Apr 3, 2024
Copy link
Contributor

github-actions bot commented Apr 3, 2024

Uffizzi Preview deployment-49437 was deleted.

@codecov-commenter
Copy link

codecov-commenter commented Apr 3, 2024

Codecov Report

Attention: Patch coverage is 97.45223% with 4 lines in your changes are missing coverage. Please review.

Project coverage is 95.88%. Comparing base (53e728a) to head (245cc37).

Files Patch % Lines
api/organisations/tasks.py 90.69% 4 Missing ⚠️
Additional details and impacted files
@@           Coverage Diff            @@
##             main    #3714    +/-   ##
========================================
  Coverage   95.87%   95.88%            
========================================
  Files        1133     1134     +1     
  Lines       35873    36025   +152     
========================================
+ Hits        34393    34541   +148     
- Misses       1480     1484     +4     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@@ -189,7 +197,81 @@ def handle_api_usage_notifications():
)


def restrict_use_due_to_api_limit_grace_period_over() -> None:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should perhaps have a flag to control this behaviour similar to the one that we added for the usage notifications task?

I wonder if the flag could also include a value that defines which fields to update on the organisation in case we want to start by just blocking access to admin for example, rather than immediately stopping serving flags.

Copy link
Contributor Author

@zachaysan zachaysan Apr 19, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I understand what you're asking for here, but just to be clear:

Once this task has been run, but before the individual filtered organisations have been modified we would have to run something like this:

for organisation in organisations:
    stop_serving_flags_enabled = flagsmith_client.get_identity_flags(
        f"org.{organisation.id}.{organisation.name}",
        traits={"organisation_id": organisation.id},
    ).is_feature_enabled("api_limiting_stop_serving_flags")
    
    blog_access_to_admin_enabled = flagsmith_client.get_identity_flags(
        f"org.{organisation.id}.{organisation.name}",
        traits={"organisation_id": organisation.id},
    ).is_feature_enabled("api_limiting_block_access_to_admin")

And then if either of the features are enabled, then the bulk update would include those files. Am I understanding this correctly?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was more thinking something along the lines of:

for organisation in organisations:
    flags = flagsmith_client.get_identity_flags(...)
    if flags.is_feature_enabled("api_limiting"):
        fields_to_update = json.looads(flags.get_feature_value("api_limiting"))["fields_to_update"]
        for field, value in fields_to_update.items():
            setattr(organisation, field, value)
        organisation.save()

... but maybe that's a bit over complicated / error prone. Perhaps your solution is better (although we should at least make sure that we separate out the call to get the flags and call is_feature_enabled() on the resultant Flags object rather than calling get_identity_flags twice).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the biggest deciding factor should be how onerous it will be to update the flags once we're ready in production. My gut is slightly in favour of using individual flags over the feature values because it seems simpler to set them to enabled for the identity flags, but that may just be an incorrect understanding of how much time it will take to individually set the fields to update in your method.

If you were in change of the Flagsmith flags for this change which approach would be more efficient?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you're right tbh, individual flags are easier to manage.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@zachaysan I think there's still work to be done here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok I've added the flagsmith flags and updated how the update logic works.

@matthewelwell matthewelwell added this pull request to the merge queue May 7, 2024
Merged via the queue into main with commit e2cb7eb May 7, 2024
22 checks passed
@matthewelwell matthewelwell deleted the feat/block_access_after_seven_days_notice branch May 7, 2024 10:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
api Issue related to the REST API
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants