Repository navigation
chore!: pass the loaded flags to onFeatureFlags and reloadFeatureFlags - #664
turnipdabeets wants to merge 7 commits into
Conversation
There was a problem hiding this comment.
PostHog Review · Standard · reviewed 93f0034: 1 Should fix.
This is the only automatic review while this pull request is a draft. Comment @posthog review to review new changes sooner. Otherwise, a review of the new changes runs when you mark it ready for review.
See this review and its findings in PostHog Review. Comment @posthog review --deep for a Deep review. A Deep review takes longer and looks deeper than a Standard review.
posthog-flutter Compliance ReportDate: 2026-10-26 18:44:26 UTC ✅ All Tests Passed!45/45 tests passed Capture Tests✅ 29/29 tests passed View Details
Feature_Flags Tests✅ 16/16 tests passed View Details
|
| return await reloaded.future.timeout( | ||
| Duration(milliseconds: 2 * (requestTimeoutMs ?? 3000)), | ||
| onTimeout: currentFlags, |
There was a problem hiding this comment.
P2 · Allow supported retries to finish before reporting failure
When posthog-js retries a timed-out request, two request timeouts plus its retry backoff exceed this deadline. A successful retry then arrives after Flutter has returned cached flags with errorsLoading: true, violating the completion contract required by AGENTS.md. Account for configured retries and backoff before applying the fallback.
2aa9ae4 to
da3dedd
Compare
onFeatureFlags and reloadFeatureFlags now carry a PostHogFeatureFlagsLoaded with the enabled flags, their values and whether loading failed, matching posthog-ios 4.0 and posthog-android 4.0. On web, reloadFeatureFlags completes right away with the flags loaded so far, because posthog-js doesn't report when a reload finishes.
Wait for the next posthog-js onFeatureFlags call instead of returning the flags already loaded, so a failed reload reports errorsLoading. Complete right away when flags are disabled, and after twice the flags request timeout when posthog-js skips the request without calling back.
The next onFeatureFlags callback can carry a response from a request already in flight, so reloadFeatureFlags() could complete with flags from before the reload. posthog-js 1.438.2+ settles reloadFeatureFlagsAsync() after this reload's own request; use it when present and keep the callback path for older posthog-js.
de3a190 to
0a7ab2a
Compare
💡 Motivation and Context
PostHogConfig.onFeatureFlagswas avoid Function()andreloadFeatureFlags()returnedFuture<void>, so Flutter apps couldn't tell what loaded or whether loading failed. posthog-ios 4.0 passes this to its listener and reload callback (PostHog/posthog-ios#897, #913), posthog-android 4.0 gets the same (PostHog/posthog-android#877), and posthog-js already passes it toonFeatureFlags.Closes #231
Both now carry a new
PostHogFeatureFlagsLoaded:flagsvariantstrueor the variant string; disabled flags left outerrorsLoadingtruewhen the latest load failed; the values are then the last known onesPer platform:
onFeatureFlagsreloadFeatureFlags()onFeatureFlagsreloadFeatureFlags(_:)PostHogFeatureFlagsCallbackreloadFeatureFlagsonFeatureFlagsfeatureFlags.reloadFeatureFlagsAsync(), which settles after this reload's own request (not one already in flight);errorsLoadingunless it loaded. Older posthog-js: the nextonFeatureFlagscall, with a timeout of twicefeature_flag_request_timeout_msfromMapstays internal (channel_serialization.dart), in line with #646.Breaking:
onFeatureFlags = () { … }becomes(loaded) { … }or(_) { … }. Callers ofreloadFeatureFlags()are unaffected; custom platform interface implementations must return the new type.Depends on #663 (posthog-android 4.0). The Android code is written against the
PostHogFeatureFlagsLoadedposthog-android 4.0 adds, which is still in review, so this stays a draft until that API is final.💚 How did you test it?
flutter analyze,flutter test(1258 pass),dart format,scripts/check-api-dart.sh(snapshot updated).reloadFeatureFlags()returns the loaded flags, and after a failed request returns the last known flags witherrorsLoading: true, as doesonFeatureFlags. The desktop test fails whenerrorsLoadingis hardcoded tofalse.flutter build ios --simulatoragainst a local posthog-ios 4.0 checkout (temporary.package(path:), reverted), andflutter build web.reloadFeatureFlagsawaitsreloadFeatureFlagsAsync()when present and reportserrorsLoadingwhen posthog-js skips the request; the first test fails without that path.📝 Checklist
If releasing new changes
pnpm changesetto generate a changeset file🤖 Agent context
Autonomy: Human-driven (agent-assisted)
Claude Code (Claude Opus 5.5) made this as part of the feature flag parity work across the iOS, Android and Flutter majors. The field names mirror posthog-ios's
PostHogFeatureFlagsLoaded. For webreloadFeatureFlags(), waiting only for the next posthog-jsonFeatureFlagscall could return a response from a request already in flight, and never fires when posthog-js skips the request, so newer posthog-js usesreloadFeatureFlagsAsync()and older versions keep that path behind a timeout.🤖 Generated with Claude Code