Skip to content

feat(flags): switch local evaluation endpoint to /flags/definitions#119

Open
patricio-posthog wants to merge 7 commits intomainfrom
feat/flags-definitions-endpoint
Open

feat(flags): switch local evaluation endpoint to /flags/definitions#119
patricio-posthog wants to merge 7 commits intomainfrom
feat/flags-definitions-endpoint

Conversation

@patricio-posthog
Copy link
Copy Markdown

Motivation and Context

The Rust feature flags definitions fleet now serves 100% of /api/feature_flag/local_evaluation traffic in all environments. This switches the SDK's default polling URL from the legacy Django path to the Rust endpoint's native path (/flags/definitions).

The old /api/feature_flag/local_evaluation path remains registered as a route alias on the Rust service, so older SDK versions continue to work.

How did you test it?

  • Updated all test mock HTTP paths to match the new endpoint
  • The /flags/definitions endpoint has been serving production traffic since 2026-04-09

Match /flags/definitions for local eval and /flags/? for decide endpoint
instead of ambiguous prefix matching on /flags/
Rust returns 401 as a plain text body without a JSON 'detail' key,
unlike Django which returned JSON. Check the HTTP status code first
so auth failures are caught regardless of response format.
…n-200 error handling

- Use exact path matching for decide endpoint (/flags/?) vs definitions (/flags/definitions)
- Update ETag test to expect exception on 500 responses (loadFlags now throws on non-200)
Comment thread lib/Client.php
Comment on lines +688 to +690
if ($responseCode !== 200) {
throw new Exception("Failed to load feature flags (HTTP $responseCode): " . $response->getResponse());
}
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Can we error_log here instead? We typically try never to raise exceptions from within the SDK otherwise we risk introducing the risk of a panic into the consuming application unless properly handled.

I realize we're doing it right below this, but it's probably worth us addressing that separately.

Otherwise this change looks good!

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

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

Good catch, I'll do it

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants