[Pwuts]

Why

Feature-flag evaluation is locked to LaunchDarkly, while PostHog is already installed, configured and running in production on both backend and frontend — its feature flags serve the onboarding pricing experiment today. The platform carries two flag systems that know nothing about each other, and nothing can move between them until the call sites stop naming a vendor.

LaunchDarkly also fits the evaluation contract badly. #14308 added evaluate_feature_flag() -> (enabled, authoritative) because variation() returns your default on failure and gives the caller no way to tell that apart from a real "off" — which matters when "off" deletes a user's schedule. That PR reconstructs the distinction from three signals. PostHog reports it natively: get_flag() returns None when the flag could not be evaluated and False when it conclusively matched no release condition. The frontend twin is useFlagStatus's answered: on PostHog it turns true once posthog-js has answered /flags live this page load, not off a snapshot persisted from an earlier visit.

What

A deployment can now answer every flag read from PostHog instead of LaunchDarkly, or from both at once, without a single call site changing. FEATURE_FLAG_BACKEND / NEXT_PUBLIC_FEATURE_FLAG_BACKEND selects launchdarkly, posthog, or dual; in dual both vendors are evaluated, LaunchDarkly's answer is served, and disagreements are recorded.

Nothing changes for users. The default stays launchdarkly and that path is byte-identical to today: no flag is deleted, no LaunchDarkly dependency is removed, and no PostHog flag has to exist yet. This is the code side of the LaunchDarkly → PostHog migration; the flags themselves move in phase 2.

In posthog and dual mode the attributes the ported targeting rules match on (role, email_domain, created_at, and the per-request country the trial offer passes) reach PostHog for flag evaluation only: the frontend sends them with /flags via setPersonPropertiesForFlags and never stores them on the person profile, and the backend passes them per evaluation. posthog.identify is unchanged in every mode, and no raw email goes to flag evaluation.

How

_evaluate_flag_value (backend) and useFlagSource (frontend) became the single dispatch point every read passes through, so each call site keeps its signature. FORCE_FLAG_* and the FORCE_ALL_FLAGS master switch short-circuit before any vendor, on the evaluator and on both route gates, so they work in all three modes and local dev, CI and Playwright are unaffected throughout.

A PostHog flag's payload stands in for LaunchDarkly's JSON variation value, which is why the payload-valued flags and the four "system"-keyed config reads need no call-site change.

Dual mode is what makes the port measurable rather than hopeful. A disagreement — in the value or in whether the answer was authoritative — is logged as one JSON record on the backend.util.feature_flag.mismatch logger: flag key, truncated SHA-256 of the user id, both values, both authoritativeness bits. A flag PostHog could not answer at all, which is every flag until phase 2 creates them, is logged once per flag per process rather than on every read. The frontend reports the same shape to console.warn and to PostHog as a feature_flag_mismatch event. PostHog is evaluated off the caller's path, so nothing waits for it, and both vendors share one user-context lookup so they cannot drift. Records for the 19 flags whose LaunchDarkly targeting is segment or individual-user membership carry expected_until_cohorts_exist, marking the disagreements that exist by construction until phase 2 builds the cohorts. Run dual with POSTHOG_PERSONAL_API_KEY set or every read pays a remote /flags call; the backend warns at startup when it is missing. PostHog reads run on a dedicated 8-worker pool rather than the process-wide default executor, so a burst of slow reads queues there instead of starving every other blocking call.

Changes 🏗️

Backend

• backend/util/feature_flag/posthog.py (new): PostHog flag client with local evaluation, built once under a lock, and evaluate_flag() returning (value, evaluated); an explicit "off" wins over a payload.
• backend/util/feature_flag/__init__.py: _evaluate_flag_value is now a dispatcher over _evaluate_launchdarkly / _evaluate_posthog / _evaluate_dual. Public API (Flag, is_feature_enabled, evaluate_feature_flag, get_feature_flag_value, feature_flag, create_feature_flag_dependency) is unchanged.
• The flag code moves from a flat backend/util/feature_flag.py into the package backend/util/feature_flag/, so the vendor implementations sit beside the dispatcher instead of adding sibling feature_flag_*.py modules. The body stays the package's __init__.py, so backend.util.feature_flag remains one module object: the import path, the backend.util.feature_flag.mismatch logger name and every test that patches a module attribute are unchanged.
• Person properties for PostHog targeting (role, email_domain, created_at) are derived from the same cached user-context lookup LaunchDarkly uses, so both vendors see one database read. Per-request attributes passed to get_feature_flag_value (the visitor's country, which the trial offer's targeting rule reads) are layered onto that context once, in the dispatcher, so LaunchDarkly, PostHog and both halves of dual evaluate the same facts; PostHog receives country as a person property.
• initialize_feature_flags() / shutdown_feature_flags() replace the LaunchDarkly-specific lifecycle hooks in rest_api.py and scheduler.py; the readiness gates in the FastAPI dependency and the @feature_flag decorator now ask the configured backend.

Frontend

• services/feature-flags/flag-source.ts (new): one seam every flag read passes through, useFlagSource(key) -> {value, resolved}, with LaunchDarkly, PostHog and dual implementations under backends/. The implementation is picked once at module load, so in launchdarkly mode the PostHog hooks are never called.
• withFeatureFlag, FeatureFlagPage and FeatureFlagRedirect read through the seam instead of the LaunchDarkly SDK — withFeatureFlag navigates to /404 only on an answer (useFlagStatus(...).answered), never on the 5 s timeout, as on dev — and the onboarding wizard waits on useFlagStatus(...).ready rather than useLDClient().waitForInitialization(). The SDK is now imported by exactly two source files inside the feature-flag service, the provider and the LaunchDarkly backend, and by one outside it: services/experiments/useLaunchDarklyExperiment.ts, which dev added in feat(platform): record A/B experiment arms per user #14287 for the A/B experiment arms and which is not a flag read.
• dual serves whichever vendor is configured and reports a disagreement only once both have answered — the two never resolve on the same render, so comparing earlier reports the load order rather than a divergence. PostHog counts as answered once /flags has answered live this page load, so a flag LaunchDarkly has and PostHog has never heard of is reported.
• useGetFlag / useFlagStatus keep their names, signatures and fallback behaviour, so every existing call site and every test file that stubs the flag module keeps working as it is. Two onboarding test files gain a useFlagStatus entry, because the wizard now reads readiness through the seam instead of the LaunchDarkly client.
• useGetFlag and useFlagStatus resolve a vendor's answer against the shape the flag declares rather than falling back only on null/undefined: PostHog returns a bare boolean for a flag with no payload, which would otherwise reach a JSON-valued flag's consumer as true and fail at .map.
• The flag-targeting attributes (email_domain, role, created_at) go to PostHog through setPersonPropertiesForFlags, only when PostHog answers flag reads; posthog.identify sends exactly what it sends on dev.

Configuration

• backend/.env.default: FEATURE_FLAG_BACKEND (default launchdarkly), POSTHOG_PERSONAL_API_KEY
• frontend/.env.default: NEXT_PUBLIC_FEATURE_FLAG_BACKEND (default launchdarkly)

Verified

I executed the backend flag suites, the whole backend/util package and the full frontend unit suite locally. feature_flag/feature_flag_test.py passes with every assertion unchanged (73 tests) — its only edit is where its source scanner computes the backend root, which the package move forced — and that, plus explicit tests asserting the default mode never calls the PostHog evaluator and never asks it about readiness, is what proves this is a no-op while the default stands. New tests cover each evaluator, the payload mapping for JSON-valued flags, person-property passthrough for exactly the attributes the ported rules target on, dual-mode mismatch logging (including the authoritative-vs-not case, an unserializable value, and the once-per-flag record while PostHog cannot answer), single construction of the flag client under concurrent first reads, and FORCE_FLAG_* in all three modes. The trial's country rule (offered everywhere but India, and not to a visitor with no country) is tested through the real LaunchDarkly evaluator and a real locally-evaluating PostHog client in each of the three modes; dropping the attribute layering turns six of its twelve cases red. On the frontend, new tests cover the three backends through the real hooks, prove the seam is mockable on its own, pin that a timeout never redirects and that identify carries no flag properties, and pin the shape check for array, object and primitive flags — I confirmed that last one can fail by reverting the resolver to the nullish fallback, which turns five of its nine cases red. Counts, the one environmental exclusion, and the nine setting-flip defects found and fixed before merge are in the evidence comment below.

Not tested end-to-end against live PostHog: no PostHog flags exist yet, which is phase 2's first task. The PostHog evaluator is exercised against a stubbed SDK snapshot, not the wire.

Phase plan

• Phase 1 (this PR) — both implementations, the setting, the dual-run diff, no behaviour change.
• Phase 2 — re-create the 19 flags carrying non-trivial targeting in PostHog from the LaunchDarkly export (individual users, six segments, email-domain/role/created_at rules; no percentage rollouts to reproduce), point the four "system"-keyed config reads at Remote Config flags, run dual for a week and drive the mismatch log to zero. Migrate the 94 frontend test files that mock the flag module onto the seam this PR adds.
• Phase 3 — switch the default to posthog, then delete LaunchDarkly: the launchdarkly-server-sdk and launchdarkly-react-client-sdk dependencies, the launch_darkly_sdk_key setting, three env vars, the lifecycle hooks, and the flag keys no code reads any more — on this head five LaunchDarkly flags (agent-briefing, api-keys-feature, autopilot-context-trimming, builder-chat-panel, chat-context-panel) and the backend's declared-but-unread dream-web-fact-check-enabled.

Checklist 📋

For code changes:

• I have clearly listed my changes in the PR description
• I have made a test plan
• I have tested my changes according to the test plan:
  • feature_flag_test.py passes unchanged, proving the default evaluation path is untouched
  • Each evaluator answers correctly, including PostHog's native "could not evaluate"
  • Dual mode returns LaunchDarkly's answer and logs a structured record on disagreement
  • FORCE_FLAG_* and FORCE_ALL_FLAGS answer without any vendor, in all three modes, through the evaluator and both route gates
  • Frontend hooks keep their contract on each backend, and the new seam is mockable alone
  • The trial offer's country rule decides the same way in all three modes

For configuration changes:

• .env.default is updated or already compatible with my changes
• docker-compose.yml is updated or already compatible with my changes
• I have included a list of my configuration changes in the PR description (under Changes)

🤖 Generated with Claude Code

[Pwuts]

🤖

Summary — no code context needed

Test evidence for this PR, which adds a second feature-flag vendor behind the API the code already calls. Every number below is from an execution in this worktree, not a reasoned claim; the two runs that did not go clean are explained rather than omitted.

Backend — .claude/bin/pytest.sh

Suite	Result	What it proves
backend/util/feature_flag_test.py	44 passed, file unchanged	the LaunchDarkly evaluation path is untouched
backend/util/feature_flag_backends_test.py (new)	28 passed	backend selection, PostHog evaluation, dual-mode mismatch logging, FORCE_FLAG_* in all three modes
backend/util/feature_flag_posthog_test.py (new)	14 passed	client construction and lifecycle, the raw read, payload preference, failure paths
backend/executor/scheduler_test.py -k FeatureFlagLifecycle	4 passed	the renamed scheduler lifecycle hooks still gate on non-LOCAL
backend/util (whole package)	851 passed	nothing else in util regressed

The "no-op" claim rests on three tests specifically: test_the_default_never_touches_posthog (the PostHog evaluator is never called), test_readiness_asks_only_launchdarkly (nor is it asked about readiness), and test_lifecycle_starts_only_launchdarkly — plus the 44 unchanged tests.

One exclusion: backend/util/service_test.py was excluded from the package run. It binds fixed ports and another worktree on this machine was running poetry run app on 8001–8009 at the time, so it hangs for anyone right now. It is not touched by this PR — the diff contains no backend/util/service.py change.

Frontend — pnpm vitest run

Suite	Result
src/services/feature-flags	42 passed (5 files: 3 pre-existing unchanged, 2 new)
whole unit suite	6102 passed / 6103

The single failure is MarketplaceStep.test.tsx > searches marketplace and library workflows, which passes on its own (4 passed) and passed in a second full-suite run — flaky under load, and it touches no flag code.

Locale note for anyone reproducing this: an earlier full run showed 18 failures across 14 files, all thousands-separators and date formatting ('28 apr 2026' vs /Apr 28, 2026/, 1.200 runs vs 1,200 runs). That is this machine's nl_NL locale, not the code. Re-running those files with LANG=en_US.UTF-8 gave 162 passed / 162. CI runs en-US, so it never sees them.

Not executed

The PostHog evaluator is exercised against a stubbed SDK snapshot, not against live PostHog: no PostHog flags exist for these keys yet, which is phase 2's first task. What is verified is the mapping — that get_flag() is None becomes "not authoritative", that a payload stands in for a JSON variation, that person properties carry every attribute the LaunchDarkly rules target on (role, email, email_domain, created_at), and that a degraded user-context lookup makes the answer unauthoritative exactly as it does on LaunchDarkly.

Operational note for the phase-2 diff week

Run dual with POSTHOG_PERSONAL_API_KEY set. Without it the PostHog SDK cannot evaluate locally and every flag read pays a remote /flags call on top of the LaunchDarkly read. The SDK dedupes its $feature_flag_called events per (distinct id, flag, value), so event volume during the diff week is bounded rather than per-read.

[coderabbitai]

Navigate logical layers of code changes, visualize relationships, and explore their blast radius.

Note

Reviews paused

It looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the reviews.auto_review.auto_pause_after_reviewed_commits setting.

Use the following commands to manage reviews:

• @coderabbitai resume to resume automatic reviews.
• @coderabbitai review to trigger a single review.

Use the checkboxes below for quick actions:

• ▶️ Resume reviews
• 🔍 Trigger review

Walkthrough

The pull request adds configurable LaunchDarkly, PostHog, and dual feature-flag backends. It updates backend lifecycle handling, frontend flag sources, gated consumers, targeting properties, overrides, and related tests.

Changes

Feature-flag backend support

Layer / File(s)	Summary
Backend selection and evaluation autogpt_platform/backend/backend/util/feature_flag/*, autogpt_platform/backend/backend/util/settings.py, autogpt_platform/backend/.env.default, autogpt_platform/backend/backend/util/metrics.py	Adds LaunchDarkly, PostHog, and dual backend selection. Adds PostHog evaluation, dual shadow reads, mismatch logging, targeting properties, lifecycle management, overrides, and backend-aware readiness checks.
Backend lifecycle wiring and validation autogpt_platform/backend/backend/api/rest_api.py, autogpt_platform/backend/backend/executor/*, autogpt_platform/backend/backend/util/feature_flag/feature_flag_test.py	Renames initialization and shutdown paths to use vendor-neutral feature-flag functions. Updates REST API, scheduler, and related tests.
Frontend backend selection and flag source autogpt_platform/frontend/.env.default, autogpt_platform/frontend/src/services/feature-flags/{flag-backend.ts,flag-source.ts,helpers.ts,use-get-flag.ts}, autogpt_platform/frontend/src/services/feature-flags/backends/*, autogpt_platform/frontend/src/services/feature-flags/feature-flag-provider.tsx	Adds frontend backend selection and shared flag-source results. LaunchDarkly, PostHog, and dual hooks expose values and resolution state.
Frontend consumers and validation autogpt_platform/frontend/src/services/feature-flags/{FeatureFlagPage.tsx,FeatureFlagRedirect.tsx,with-feature-flag.tsx}, autogpt_platform/frontend/src/app/*, autogpt_platform/frontend/src/providers/posthog/posthog-provider.tsx, autogpt_platform/frontend/src/services/feature-flags/__tests__/*	Updates gated pages, onboarding, typed flag usage, PostHog person properties, value-shape handling, and tests to use vendor-neutral readiness and flag status.

Priority: ➖ Normal

Estimated code review effort: 4 (Complex) | ~60 minutes

Change: Feature

Sequence Diagram(s)

sequenceDiagram
  participant FeatureGatedPage
  participant useFlagStatus
  participant useFlagSource
  participant LaunchDarkly
  participant PostHog
  FeatureGatedPage->>useFlagStatus: request flag status
  useFlagStatus->>useFlagSource: read value and resolution
  useFlagSource->>LaunchDarkly: read selected flag
  useFlagSource->>PostHog: read selected or shadow flag
  useFlagSource-->>useFlagStatus: return value and readiness
  useFlagStatus-->>FeatureGatedPage: render or redirect

Loading

Merge Risk: 🟡 Moderate · up to 42ae7

PostHog flag-read workers can remain active during shutdown and delay service termination. Define executor cancellation, active-read bounds, and reinitialization behavior before merging.

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 43.84% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 146 functions across 32 files.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Title check	✅ Passed	The title clearly summarizes the main change: adding a PostHog feature-flag backend while preserving the existing API.
Description check	✅ Passed	The description is directly related to the changeset and provides detailed context, implementation details, testing evidence, and rollout phases.

• Fix all pre-merge checks with AI

✨ Finishing Touches 💡 2

📝 Generate docstrings 💡

• Commit to this branch
• Create a new PR

🧪 Generate unit tests (beta)

• Commit to this branch
• Create a new PR

🛠️ Fix failing CI checks 💡

• Commit to this branch
• Create a new PR

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[codecov]

Codecov Report

❌ Patch coverage is 96.51685% with 31 lines in your changes missing coverage. Please review.
✅ Project coverage is 84.02%. Comparing base (da73bf7) to head (c66a462).

Additional details and impacted files

@@            Coverage Diff             @@
##              dev   #14317      +/-   ##
==========================================
+ Coverage   83.96%   84.02%   +0.05%     
==========================================
  Files        4091     4099       +8     
  Lines      308804   309590     +786     
  Branches    27971    28268     +297     
==========================================
+ Hits       259289   260130     +841     
+ Misses      44828    44767      -61     
- Partials     4687     4693       +6     

Flag	Coverage Δ
platform-backend	88.25% <97.61%> (+0.03%)	⬆️
platform-frontend	65.38% <86.51%> (+0.11%)	⬆️
platform-frontend-e2e	27.61% <37.50%> (+0.12%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Components	Coverage Δ
Platform Backend	88.27% <97.61%> (+0.03%)	⬆️
Platform Frontend	67.22% <87.09%> (+0.14%)	⬆️
AutoGPT Libs	∅ <ø> (∅)
Classic AutoGPT	28.43% <ø> (ø)

🚀 New features to boost your workflow:

• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[Pwuts]

🤖

Summary — no code context needed

What the blast-radius review of this PR asked for, and what each fix is verified by. The PR adds a second feature-flag vendor (PostHog) behind the API the code already calls; every finding below is reachable only by moving FEATURE_FLAG_BACKEND off its default, which is what the PR exists to make possible. The default path was already confirmed byte-identical and is unchanged by this round.

Findings and how each was closed

#	Fix	Verified by
F1	withFeatureFlag, FeatureFlagPage, FeatureFlagRedirect and the onboarding wizard read through useFlagSource instead of the LaunchDarkly SDK. withFeatureFlag now takes a Flag rather than a raw string.	New with-feature-flag.test.tsx drives it through the seam with no vendor SDK mocked at all: renders on true, redirects to /404 on false, and waits without redirecting while the answer is outstanding. grep launchdarkly-react-client-sdk src/ now returns exactly two files — the provider and the LaunchDarkly backend.
F2	The frontend dual mismatch fires only once both vendors have resolved.	Two tests: "stays quiet while only one vendor has answered" (rerender during the race, zero captures) and "reports once LaunchDarkly catches up and still disagrees" (exactly one capture).
F3	dual shares one user-context lookup and evaluates PostHog off the caller's path, under a bounded backlog. Startup warns when POSTHOG_PERSONAL_API_KEY is missing.	The reviewer's own probe, re-run: PROBE1 degraded-path DB lookups per evaluation: launchdarkly=1 dual=1 (was dual=2) and PROBE2 per-evaluation latency with a 400ms PostHog call: launchdarkly=0.1ms dual=0.1ms (was dual=400.9ms). Three tests cover it, including one that resolves a dual read inside 5s while PostHog sleeps 30s, and one that caps the backlog.
F4	dual serves whichever vendor is configured; isPostHogFlagsEnabled gains the cloud check that gates PostHogProvider.	"serves PostHog when LaunchDarkly is not configured" asserts {enabled: true, ready: true} where the probe measured {enabled: false, ready: false}; a second test asserts no mismatch is reported when only one vendor is configured; a third asserts posthog mode falls back to defaults outside cloud.
F5	shutdown_posthog_flags clears _init_attempted.	"the client can be rebuilt after shutdown" asserts a second client is constructed.
F6	Unknown FEATURE_FLAG_BACKEND falls back to launchdarkly with a warning, case-insensitively.	Two tests on Config() directly — Settings.config is a class-level default built once at import, so a test that constructs Settings() cannot see a monkeypatched env var. Manual check: FEATURE_FLAG_BACKEND=posthogg logs the warning and yields LAUNCHDARKLY; PostHog yields POSTHOG.
F7	Kept, with the intent written down in the code and in the PR body: role/email_domain/created_at are what the ported targeting rules match on. Still a no-op in launchdarkly mode.	The existing buildFlagPersonProperties tests.
F8	Mismatch records carry expected_until_cohorts_exist, from a 19-key set built from ld-targeting-summary.md (segment membership or individual-user targets; attribute rules are excluded because _person_properties already carries them).	"segment-targeted flags are marked as expected" asserts the marker is true for graphiti-memory, and the pre-existing mismatch test asserts false for hire-experts.
F9	sentry_init gates the LaunchDarkly integration on serves_launchdarkly().	Import check; no behaviour change in the default or dual mode.

One defect the probe found that the report did not list

PROBE4 in the reviewer's backend probe showed OFF flag carrying a payload -> evaluate_feature_flag = (False, False). A flag PostHog had conclusively answered "off" for was being read as "could not evaluate", because the payload was preferred over the value and a payload is not a boolean. That is precisely the distinction this evaluator exists to preserve, so a conclusive False now wins over a payload. The probe reads (False, True) after the fix, and a test pins it.

Suites executed

Suite	Result
feature_flag_test.py, feature_flag_backends_test.py, feature_flag_posthog_test.py	94 passed (was 86; 8 new)
backend/util whole package	859 passed (was 851)
frontend src/services/feature-flags	51 passed (6 files)
frontend onboarding + settings/memory + feature-flags	324 passed (24 files)
whole frontend unit suite	6110 passed / 6110, no failures
pnpm types	clean

backend/util/service_test.py stays excluded: it binds fixed ports and another worktree on this machine holds 8001–8009. It is untouched by this PR.

The onboarding tests needed useFlagStatus added to their existing use-get-flag mock — that is a consequence of the wizard no longer reaching for the LaunchDarkly SDK, not the phase-2 mock migration, which is still deliberately out of scope. The brain-dump test's launchdarkly-react-client-sdk mock became dead and was removed.

[Pwuts]

🤖

Summary — no code context needed

Two follow-up items from the re-review of this PR, which adds a second feature-flag vendor (PostHog) behind the API the code already calls. Both are reachable only in the non-default modes. Fixed in 1d57fe96b4.

N1 — a shadow flag read racing teardown resurrected the client

In dual mode the backend evaluates PostHog off the caller's path as a background task. One still in flight at shutdown resumed afterwards, called get_flag_client(), and — because shutdown clears the "did we try" gate so an in-process restart works (F5) — built a fresh PostHog client with a poller thread nothing closes.

shutdown_feature_flags() now cancels the in-flight reads and refuses new ones until the next initialize_feature_flags(), which keeps the restart F5 exists for. That is the same hazard shutdown_launchdarkly documents for its own gate, handled the same way.

I cancelled and gated rather than cancelled and awaited: shutdown_feature_flags is synchronous — rest_api.feature_flag_context and the scheduler both call it from a sync frame — so there is no point at which it can await. Refusing new probes is what actually closes the resurrection, since the rebuild happens in get_flag_client() at the start of a probe that had not started yet.

Re-running the reviewer's probe shape:

PROBE5  in-flight shadow tasks: before shutdown=1 after=0 -> shutdown drains them: True
PROBE10 after a late read: _client=None threads=2 (was 2)

Previously after=1, _client=REBUILT, threads=3.

Three tests pin it: shutdown cancels the in-flight set, a read arriving during teardown never reaches get_flag_client(), and a restart re-enables shadow evaluation.

N2 — the dual docs claimed an invariant the F4 fix retired

dual was sold as "serve LaunchDarkly", and after F4 the frontend serves PostHog where LaunchDarkly is not configured — serving LaunchDarkly's never-arriving answer was the bug. The backend still serves LaunchDarkly unconditionally, so the two sides genuinely differ and the docs now say so rather than implying one rule:

• frontend/.env.default — "serve LaunchDarkly when it is configured — otherwise PostHog, since LaunchDarkly's answer never arrives without its provider"
• backend/.env.default — "always serve LaunchDarkly here"
• the FeatureFlagBackend docstring — states both halves explicitly, and no longer claims dual changes nothing any user sees

Suites executed

Suite	Result
feature_flag_test.py, feature_flag_backends_test.py, feature_flag_posthog_test.py	97 passed (was 94; 3 new)
the reviewer's original backend probe, re-run	PROBE1 dual=1 lookup, PROBE2 dual=0.1ms, PROBE3 LaunchDarkly's answer preserved, PROBE4 (False, True)

[Pwuts]

🤖 Evidence and review history

Review round

A blast-radius review confirmed the default path is byte-identical and found nine issues, all reachable only by flipping the setting. Fixed here: two live components read the LaunchDarkly SDK directly and would have hung /settings/memory and the onboarding wizard in posthog mode; dual reported a mismatch per flag per page load from the vendor load race, waited for the discarded PostHog answer on every backend read, and doubled the degraded user-context lookup; dual with LaunchDarkly disabled served defaults and stalled five seconds; the PostHog client could not be rebuilt after shutdown; an invalid FEATURE_FLAG_BACKEND crashed at boot instead of falling back; sentry_init built a LaunchDarkly client in posthog mode. A probe also caught a defect of its own: a conclusive "off" carrying a payload read as "could not evaluate", which is the one distinction this evaluator exists to preserve.

[github-actions]

This pull request has conflicts with the base branch, please resolve those so we can evaluate the pull request.

[github-actions]

Conflicts have been resolved! 🎉 A maintainer will review the pull request shortly.

[github-actions]

This pull request has conflicts with the base branch, please resolve those so we can evaluate the pull request.

[autogpt-pr-reviewer]

🤖 Review of de63bd3 posted: #14317 (review)

[autogpt-pr-reviewer]

✅ Verdict: Approved — No findings require changes before approval; this review counts as an approval.

Opt-in PostHog feature-flag backend added behind the existing API, off by default, with a byte-identical LaunchDarkly path, preserved fail-closed gates, minimized PII, and strong tests proving the no-op default two ways. CI is green on de63bd3; only low-severity advisories on non-default paths remain.

Risk level: low | Human review: not required | Duration: 488s | Reviewed: de63bd3b

Findings: 🔴 0 blockers | 🟠 1 should fix | 🟡 1 nice to have | 🔵 1 nit

Optional advice — does not block approval

Follow-ups

• 🟠 autogpt_platform/frontend/src/services/feature-flags/backends/dual.ts:53 De-duplicate dual-mode mismatch capture — In opt-in dual mode the feature_flag_mismatch capture effect is keyed on the recomputed record JSON, so a stable disagreement can re-emit on re-renders. Harmless on the default path but could inflate event volume during the phase-2 diff week.
  Suggestion: Track already-reported records (e.g. a ref keyed on flag+value) so a stable mismatch is captured once.

Optional advice — does not block approval

🟡 Nice to Have

• 🔵 autogpt_platform/backend/backend/util/feature_flag/posthog.py:66 Batch flag reads when serving PostHog without local evaluation — Without POSTHOG_PERSONAL_API_KEY each evaluate_flag is a single-flag remote /flags call, so a multi-flag request pays N sequential round-trips. Opt-in, isolated to a dedicated pool, and documented.
  Suggestion: Keep local evaluation on (personal key set) for dual mode as instructed; consider request-level batching for any future PostHog-on-request-path mode.

Optional advice — does not block approval

🔵 Nits

• 🔵 autogpt_platform/backend/backend/executor/scheduler.py:1915 Make scheduler flag-lifecycle comments vendor-agnostic — Comments at lines 1915 and 2177 name LaunchDarkly, but the paired helpers now initialize/tear down whichever backend is configured. Misleading to future readers.
  Suggestion: Rewrite both comments to reference the feature-flag backend generically.

GitHub CI on reviewed head: success

Validation and specialist details

Specialist Reports

Specialist	Status	Summary
security	✅ PASS	A carefully-scoped, well-tested PostHog flag backend behind the existing API; default path is unchanged, PII to PostHog is minimized to non-identifying targeting attributes, secrets are blank in .env.default, and no fail-closed gate is bypassed.
architect	✅ PASS	Clean single-dispatch-point seam on both backend and frontend that preserves the default LaunchDarkly path byte-for-byte, keeps every public signature and test stub working, and is well instrumented for a measurable migration; only minor comment-drift advisories.
performance	✅ PASS	Performance-sound: the default flag path is byte-identical, and all new costs (remote per-flag reads, shadow evaluation) are opt-in, bounded, and isolated to a dedicated worker pool off the request path.
testing	✅ PASS	Comprehensive, high-signal test suite that proves the Phase-1 no-op guarantee two ways and asserts exact evaluator/mismatch semantics; no blocking test defects found.
quality	✅ PASS	High-quality, well-documented feature-flag backend abstraction with comprehensive tests and a byte-identical default path; no concrete code-quality defects found.
product	✅ PASS	PostHog flag backend added behind the existing API as an opt-in, default-preserving no-op with strong test coverage and preserved UX/loading/redirect behavior; no user-facing defects found.
discussion	✅ PASS	CI is green on head de63bd3 and there are no open human-reviewer requests.
ui-reviewer (local)	✅ PASS	PostHog flag backend is fully opt-in behind FEATURE_FLAG_BACKEND; the default launchdarkly path on backend and frontend is preserved and introduces no payment or other UI in local/self-hosted mode.
ui-reviewer (hosted)	✅ PASS	Phase-1 PostHog flag backend added behind an unchanged API; the default launchdarkly path is a verified no-op on both backend and frontend, the PostHog SDK contract matches the installed 7.53.0 API, and the targeted backend suites (20+42 tests) pass.

[Pwuts]

🤖 Merged dev (#14799) into this branch at c66a462. Evidence below.

Resolution, mutations, suites

Conflict. One conflict, in feature_flag/__init__.py _evaluate_launchdarkly. #14799 layered attributes onto the context inside the LaunchDarkly evaluator, but the dispatcher here never passed them on, so a naive resolution drops country in every mode, LaunchDarkly included. The resolution layers the attributes once in _evaluate_flag_value and hands that one context to all three evaluators. _person_properties now forwards country.

Added-lines proof. The sorted set of lines added against origin/dev after the merge is the pre-merge set, plus the resolution and the new test, and nothing else. The six pre-merge lines no longer present are exactly the ones the resolution replaced.

Country rule, all three modes. TestTheCountryRuleInEveryBackend runs the real LaunchDarkly TestData evaluator and a real locally-evaluating PostHog client. The rule: offered to US and BR, not to IN, and not when no country is sent. Result: 12 passed.

• Removing the layering: 6 failed (US and BR in every mode).
• Dropping country from _person_properties: 2 failed (PostHog mode).

Suites, local.

• backend/util/feature_flag/: 147 passed
• subscription_trial_{config,capacity,checkout}_test, subscription_trial_routes_test, country_test, scripts/feature_flag_sync_test, architecture_test: 191 passed
• blocks/test/test_block.py: 1755 passed, 84 skipped
• pyright over the flag package, settings.py and subscription_trial_config.py: 0 errors

Not run. The TRIAL_TEST_DATABASE-gated integration suites. Also, the trial config tests mock get_feature_flag_value, so the only proof that the country crosses the flag layer is the new test.

[Pwuts]

/review

[autogpt-pr-reviewer]

🤖 Review of c66a462 posted: #14317 (review)

[autogpt-pr-reviewer]

✅ Verdict: Approved — No findings require changes before approval; this review counts as an approval.

An opt-in PostHog feature-flag backend behind the existing API, with a byte-identical LaunchDarkly default proven no-op two ways. Security, architecture, performance, tests, and product all approve with no concrete defects; only low-severity advisories on non-default paths remain. GitHub CI is green on head c66a462.

Risk level: low | Human review: not required | Duration: 590s | Reviewed: c66a4620

Findings: 🔴 0 blockers | 🟠 1 should fix | 🟡 2 nice to have | 🔵 0 nits

Optional advice — does not block approval

Follow-ups

• 🟠 autogpt_platform/backend/backend/executor/scheduler.py:1916 Generalize stale LaunchDarkly-specific scheduler comments — Comments at 1916 and 2182 reference 'LaunchDarkly'/'LD' initialization and teardown, but the helpers they sit above now initialize/shut down whichever backend is configured. Misleading to a future reader after the migration.
  Suggestion: Rewrite both comments to be vendor-neutral (feature flag backend rather than LaunchDarkly).

Optional advice — does not block approval

🟡 Nice to Have

• 🔵 autogpt_platform/frontend/src/services/feature-flags/backends/dual.ts:31 Serialize dual-mode mismatch record lazily — record = JSON.stringify({...}) runs on every render of every flag consumer even when the mismatch is not comparable or the vendors agree, discarding the result on most renders.
  Suggestion: Compute the string inside the useEffect or guard with comparable && !agree. Dual is a temporary diagnostic mode.
• 🔵 autogpt_platform/backend/backend/util/metrics.py:273 Add test for serves_launchdarkly() Sentry gate — The gate that stops wiring LaunchDarklyIntegration into Sentry under posthog mode has no test; metrics_test.py never asserts the integration list is empty in posthog mode.
  Suggestion: Add a unit test spying sentry_init that patches serves_launchdarkly() to False and asserts no LaunchDarklyIntegration is appended.

GitHub CI on reviewed head: success

Validation and specialist details

Specialist Reports

Specialist	Status	Summary
security	✅ PASS	PostHog feature-flag backend behind an opt-in setting with the default path unchanged; secrets kept blank, user ids pseudonymized in logs, no raw email sent to flag evaluation, and route gates fail closed — no concrete security defect found.
architect	✅ PASS	A cleanly-dispatched, backwards-compatible PostHog flag backend behind the existing API with a byte-identical default path; only minor stale-comment nits.
performance	✅ PASS	Default flag path is unchanged and the opt-in PostHog/dual paths are carefully bounded (off-path shadow eval, 100-task cap, dedicated 8-worker pool, shared cached context lookup); only minor advisory optimizations remain.
testing	✅ PASS	Thorough, faithful test suite covering the default no-op path, each vendor evaluator, dual-mode mismatch logging, shutdown/concurrency races, force-overrides on both gates, and the frontend seam; only a minor advisory gap on the Sentry LaunchDarkly-integration gating.
quality	✅ PASS	High-quality, well-documented, well-tested PostHog flag backend behind the existing API; default path is a verified no-op with no concrete code-quality defects.
product	✅ PASS	PostHog flag backend added behind the existing API; a no-op in the default launchdarkly configuration with prior user-facing behavior preserved and thorough tests, so no blocking product/UX defect.
discussion	✅ PASS	CI is green on head c66a462 with no merge conflict, and there are no open unanswered requests from human reviewers.
ui-reviewer (local)	✅ PASS	PostHog flag backend added behind the existing API as a verified no-op on the default LaunchDarkly path; SDK usage confirmed against posthog 7.53.0 and new tests pass (74), with the only local failures traced to sandbox FORCE_FLAG_* env vars rather than PR code.
ui-reviewer (hosted)	✅ PASS	Default-preserving phase-1 addition of a PostHog feature-flag backend behind the existing API; targeted checks pass, the two local test failures are sandbox .env force-flag leakage (proven correct in a clean env), and no reachable defect is introduced.