fix(flags): Revert changes to remote_config endpoint - #36273
Conversation
I made some changes to the `remote_config` endpoint to try and make project selection deterministic. It turns out there's already a supported and simpler way to do it: pass the project api token in the `token` query string parameter. This is what the `local_evaluation` endpoint does, so we should follow that example. I am not reverting the changes to `ProjectSecretAPIKeyAuthentication` because those are actually needed.
There was a problem hiding this comment.
Greptile Summary
This PR reverts changes made to the remote_config endpoint in previous PRs #36154 and #36267. The original changes attempted to enable deterministic project selection by allowing POST requests with a project_api_key parameter in the request body, which would override the default behavior where personal access tokens route to whichever project the user last visited.
However, the developer discovered that PostHog already has a simpler, supported mechanism for deterministic project routing: passing the project API token directly in the token query string parameter, which is the same pattern used by the local_evaluation endpoint.
The revert involves four key changes:
posthog/api/routing.py: Removes the_get_explicit_project_api_key()method and simplifies_get_team_from_request()to only use standard token authentication mechanismsposthog/api/feature_flag.py: Changes theremote_configendpoint@actiondecorator frommethods=["GET", "POST"]back tomethods=["GET"]posthog/api/test/test_routing.py: Removes the entireTestTeamAndOrgViewSetMixinProjectApiTokentest class that was testing the reverted functionalityposthog/api/test/test_feature_flag.py: Updates the test to use query parameters instead of POST body for API token authentication
This change eliminates unnecessary complexity by removing support for POST requests and request body parsing for project selection, while maintaining the existing authentication mechanisms that already solve the deterministic routing problem. The revert aligns the remote_config endpoint with established patterns in the codebase and follows the principle of not maintaining redundant functionality.
Confidence score: 5/5
- This PR is safe to merge with minimal risk as it's a clean revert that removes complexity while maintaining existing functionality
- Score reflects that this is a well-reasoned simplification that removes unnecessary code paths and aligns with existing patterns
- No files require special attention as the changes are straightforward reverts with appropriate test updates
4 files reviewed, no comments
Problem
I made some changes to the
remote_configendpoint to try and make project selection deterministic:remote_configendpoint #36154project_api_key#36267It turns out there's already a supported and simpler way to do it: pass the project api token in the
tokenquery string parameter (like so). No changes were needed on the server.This is what the
local_evaluationendpoint does, so we should follow that example.Changes
This PR reverts changes to the
remote_configendpoint. It no longer acceptsPOSTrequests and it doesn't look in the request body for the project api token.Note: I am not reverting the changes to
ProjectSecretAPIKeyAuthenticationbecause those were actually needed.How did you test this code?
Unit Tests.
Manually.
👉 Stay up-to-date with PostHog coding conventions for a smoother review.