feat: Adds feature flags runtime client with local evaluation#1511
Draft
stanleyphu wants to merge 8 commits intomainfrom
Draft
feat: Adds feature flags runtime client with local evaluation#1511stanleyphu wants to merge 8 commits intomainfrom
stanleyphu wants to merge 8 commits intomainfrom
Conversation
Add interfaces for the runtime client: EvaluationContext, FlagPollEntry, FlagPollResponse, RuntimeClientOptions, RuntimeClientStats, and RuntimeClientLogger. These define the contract for the polling-based feature flag client. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Simple in-memory store that holds the polling response. Supports atomic swap of the full flag map, O(1) lookup by slug, and size tracking. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Synchronous flag evaluation against the in-memory store. Evaluation order: flag not found → defaultValue, flag disabled → false, org target match → target.enabled, user target match → target.enabled, no match → default_value. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
EventEmitter-based client that polls GET /sdk/feature-flags, caches flags in memory, and evaluates locally. Features: configurable polling interval with jitter, per-request timeout via Promise.race, bootstrap flags, waitUntilReady with timeout, change events on subsequent polls, and 401 detection that stops polling and emits 'failed'. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Adds createRuntimeClient() method to FeatureFlags module, allowing users to create a polling-based runtime client via workos.featureFlags.createRuntimeClient(). Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Adds exponential backoff (1s base, 2x multiplier, 60s cap) when polls fail consecutively. The backoff delay is used when it exceeds the normal polling interval, and resets after a successful poll. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
FeatureFlagsRuntimeClient, a polling-based client that fetches all flag configurations from/sdk/feature-flagsand evaluates them locally in-memory. Targeting rules (org-level and user-level) are resolved client-side with zero per-request API overhead.workos.featureFlags.createRuntimeClient(options?).Implementation Details
InMemoryStore— atomic-swap key/value store for flag dataEvaluator— stateless evaluation: flag enabled → org target → user target → default valueFeatureFlagsRuntimeClient— orchestrates polling, caching, and evaluation'failed'eventwaitUntilReady()with optional timeout'change'events when flags are added, modified, or removedgetStats()for observabilityUsage
Basic usage
With targeting context
Configuration options
Reacting to changes
Evaluating all flags at once
Observability
Cleanup
Documentation
Does this require changes to the WorkOS Docs? E.g. the API Reference or code snippets need updates.
If yes, link a related docs PR and add a docs maintainer as a reviewer. Their approval is required.