The test is missing thereset_cache fixture parameter which is used in other throttle tests to ensure proper cache cleanup between tests. DRF's ScopedRateThrottle uses Django's cache backend to track request counts, and without cache clearing, throttle state could persist between tests causing flaky test failures.

Addreset_cache to the function parameters (see examples inapi/tests/integration/custom_auth/end_to_end/test_custom_auth_integration.py lines 486-491 and 527-533).

Increasing the debounce time from 500ms to 750ms will affect all components usinguseDebouncedSearch, not just identity search. This includes:

• AuditLog.tsx
• ConversionEventSelect.tsx
• CreateSegment.tsx (segment search)
• SegmentsPage.tsx
• SplitTestPage.tsx
• UserPage.tsx
• UsersPage.tsx (identity search)
• TableValueFilter.tsx

While this may be acceptable to reduce API calls globally, consider whether a 250ms increase is appropriate for all these use cases. If the intent is to only throttle identity search, consider creating a separate hook likeuseDebouncedIdentitySearch with the higher debounce time, or make the debounce time configurable via a parameter.

@Zaimwa9 are you able to chime in here - do you think this is something we need to be concerned about?

@1-23-smy thanks for the changes, could you explain the rationale behind the increase of the debounce? If this does not conflict with the extra throttling we'd better stick to 500. We aligned on 500 being the right UX time

@1-23-smy thanks for the changes, could you explain the rationale behind the increase of the debounce? If this does not conflict with the extra throttling we'd better stick to 500. We aligned on 500 being the right UX time

Even though the impact is minimal, i would suggest to return the global default throttlesuper().get_throttles here (defaulting toDEFAULT_THROTTLE_CLASSES). Similarly to what we didhere

@Zaimwa9

• I have reverted debounce from 750ms back to 500ms (agreed UX time).
• Updated get_throttles() to return super().get_throttles() for non-list actions.

thanks a lot! Just some conflicts to fix and we should be good to enable the workflows and get it over the line. Again, thanks for the contribution, we appreciate!

Thanks for the review! the conflicts should now be resolved.

Let me know if there's anything else you'd like me to adjust!

The comment states "Apply identity_search throttle only to list (search) requests" but the implementation applies throttling to ALL list requests, regardless of whether they include a search query parameter. The current implementation throttles both/identities/ and/identities/?q=test equally.

If the intent is to only throttle search requests (when the 'q' parameter is present), the condition should check for the presence of the query parameter. Otherwise, if throttling all list requests is the intended behavior, update the comment to accurately reflect this.

The test only verifies that the list action with a search query is throttled, but it doesn't verify that other actions (create, retrieve, update, delete) are NOT throttled. Following the pattern from api/tests/integration/custom_auth/end_to_end/test_custom_auth_integration.py:563-575 (test_get_user_is_not_throttled), consider adding a test to ensure other actions on the IdentityViewSet are not affected by the throttle.

The PR description mentions "Frontend Changes" that increase debounce from 500ms to 750ms infrontend/common/useDebouncedSearch.ts, but this file is not included in the current changes. Based on previous review feedback, there were concerns about this change affecting all components using the hook, and it was suggested to stick to 500ms if there's no conflict with the backend throttling. Either include the frontend changes in this PR or remove the mention from the PR description.

Undocumented breaking change to global throttle rate defaults

Medium Severity

The PR changesUSER_THROTTLE_RATE andMASTER_API_KEY_THROTTLE_RATE defaults fromNone (no throttling) to"500/min", but this behavioral change isn't mentioned in the PR description. The stated scope is only adding rate limiting to the identity search endpoint. Existing deployments that hadDEFAULT_THROTTLE_CLASSES configured but relied on theNone default for these rates would suddenly have 500/min rate limiting applied to all admin API requests. If intentional, this change warrants explicit documentation in the PR description.