Repository navigation
ci: update SDK compliance harness to 1.26.0 - #680
Merged
Merged
Conversation
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Contributor
posthog-flutter Compliance ReportDate: 2026-10-29T01:54:30.055554+00:00 ✅ All Tests Passed!47/47 tests passed Capture Tests✅ 30/30 tests passed View Details
Feature_Flags Tests✅ 17/17 tests passed View Details
|
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
turnipdabeets
changed the title
marandaneto
approved these changes
Oct 29, 2026
marandaneto
left a comment
marandaneto
left a comment
Member
There was a problem hiding this comment.
The code looks good; no qualifying findings. Verdict: correct.
turnipdabeets
merged commit Oct 29, 2026
9016430
into
feat/v6-desktop-capture-ai
18 of 27 checks passed
turnipdabeets
added a commit
that referenced
this pull request
Oct 29, 2026
…d options passthrough (#679) * chore!: adopt posthog-ios 4.0 - Require posthog-ios 4.x. - Adapt to the reloadFeatureFlags(_:) callback that now passes a PostHogFeatureFlagsLoaded (PostHog/posthog-ios#913). - Note the payload decoding changes from PostHog/posthog-ios#903. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> * docs(changeset): note posthog-ios 4.0 drops lifecycle version and build PostHog/posthog-ios#905 removes the legacy version/build properties from lifecycle events in 4.0, so Flutter iOS and macOS apps stop sending them. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> * chore(ios): drive onFeatureFlags from the posthog-ios onFeatureFlags listener posthog-ios 4.0 removes the didReceiveFeatureFlags notification. * chore!: adopt posthog-android 4.0 * feat: add per-event capture options and captureAi Passes options and captureAi through to posthog-ios and posthog-android 4.0; Windows, Linux and web send known options as their legacy properties. * feat: add captureAi queue and request settings to PostHogConfig Add captureAiCompression, captureAiMaxQueueSize, captureAiTimeout and captureAiMaxEventBytes. Set values are sent to native setup and applied to the posthog-ios and posthog-android config; unset values are omitted so the native defaults apply. They have no effect on Windows, Linux and web. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * docs: spell out when captureAi returns null null means the event wasn't admitted: dropped by beforeSend, oversized on iOS and macOS, SDK disabled or opted out, or an unsupported platform. On Windows, Linux and web captureAi is a no-op that sends nothing. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * docs: captureAi returns null for an oversized event on Android too posthog-android now checks the size before queuing (f46a9711). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * fix: retry desktop capture v1 requests that get 404 or 429 A 404 usually means a misconfigured proxy and a 429 an overloaded Envoy; both are worth retrying with the same backoff, Retry-After handling and retry budget. Redirects stay terminal. * fix: back off across failed desktop flushes and warn once on a capture 404 After a batch fails its retries, later flushes make one attempt each and pause 6s doubling to 30s until a batch is delivered. Before, every flush, including the one each capture starts at flushAt, sent 4 requests, so a missing capture route kept resending the batch. A 404 prints one warning per client even without debug, naming the URL and the path a proxy or self-hosted instance must serve. * fix: leave the host out of the capture 404 warning A host with proxy credentials in its userinfo would print them to app logs. * chore!: pass the loaded flags to onFeatureFlags and reloadFeatureFlags (#664) * chore!: pass the loaded flags to onFeatureFlags and reloadFeatureFlags 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. * fix: complete the web reloadFeatureFlags with the reloaded flags 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. * chore: use PostHogFeatureFlagsCallback from posthog-android 4.0 * chore: fix ktlint function-signature * fix: await posthog-js reloadFeatureFlagsAsync on web 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. * docs: pass the loaded flags in the setup example * docs: drop best-effort web note from the person and group property methods * fix(web): wait for posthog-js flags retries before reporting a reload failure posthog-js retries a timed-out /flags request once by default, 500 ms later, inside the same reload. The older-JS deadline of twice the request timeout reported cached flags with errorsLoading set before a successful retry landed. * docs: note where onFeatureFlags and errorsLoading differ on Android and web * docs: describe the older posthog-js reload timeout as the full retry budget Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com> * feat(desktop): send event options unchanged in the capture v1 event On Windows and Linux, the options of capture, screen, captureException, identify, setPersonProperties, alias and group now go into the event's capture v1 `options` as they are, unknown keys included, instead of being mapped to legacy `$` properties. An option still wins over its legacy property, which is moved into `options` only when the option is unset. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * feat(desktop): build event properties in the native 4.0 order On Windows and Linux, an event's properties are now the ones the SDK sets, then the registered ones, then the event's own, each winning over the ones before, and the Dart beforeSend callbacks run after that merge. They see and can change every property and option the SDK adds, and the event is queued as they leave it. A caller or registered value changes that event only. Person processing is no longer a `$process_person_profile` property: the event carries `process_person_profile: false` in its options only while person processing is off and neither an option nor a property sets it, and omits it otherwise. The event's timestamp is taken before the callbacks run. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * fix(desktop): back off capture v1 retries like posthog-ios and posthog-android A transient failure or a 2xx whose per-event results ask to retry no longer resends within the flush (3 tries, 3 s apart). Each one pauses the queue for 1 s doubling to 30 s, with ±25% jitter from an injectable source. A Retry-After is a floor applied after the jitter, capped at 30 s, instead of replacing the backoff, so `Retry-After: 1` no longer resends every 3 s. A delivered or dropped batch resets the backoff. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * fix(desktop): time out capture requests on inactivity, not on total duration The 10 s whole-call timeout could fail a large batch on a slow uplink on every attempt. A request now fails only after 10 s without progress: connecting (HttpClient.connectionTimeout), the socket taking a 64 KiB body chunk, the response headers, or a response body chunk. This is the closest dart:io gets to the per-read/per-write idle timeouts of OkHttp and URLSession: like them, it can't see the bytes still in the kernel send buffer, so the wait for headers starts once the last chunk is handed over. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * fix(desktop): halve flushAt with the batch size on 413 and end the flush A 413 halved only the batch size and resent at once in the same flush. Like posthog-ios and posthog-android, it now also halves flushAt, kept within the batch size, and the smaller batches go out with the next flush (the next capture over flushAt, or the periodic flush). No backoff is added: posthog-ios ends the flush without one; posthog-android pauses. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * feat(desktop): send captureAi events to the capture v1 AI endpoint On Windows and Linux, captureAi now builds the event like capture, runs the Dart beforeSend callbacks, and queues it on disk apart from other events, in posthog_ai_queue/. It is sent to /i/v1/ai/events with the same wire format, batching, retry rules and backoff as analytics events, and returns the event's uuid, or null when the event isn't queued: dropped by beforeSend, opted out, or over the size limit. - A serialized event over captureAiMaxEventBytes, capped at and by default 8 MiB plus 64 KiB, measured before compression, is dropped with a log line naming only the event and its size. - The queue keeps captureAiMaxQueueSize events (100 by default) and at most 50 MiB, dropping the oldest first, and flushes as soon as 5 MiB is queued. - Requests use captureAiCompression (gzip by default) and are bounded by captureAiTimeout (60 seconds by default). - Each endpoint keeps its own retry identity, timers, backoff and 413 batch size, so a failing AI request doesn't hold back other events. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * docs: describe desktop captureAi, options and property order in changesets Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * fix(desktop): flush once 5 MiB of events are queued Like posthog-ios and posthog-android, a full capture v1 request's worth of queued bytes (captureV1MaxBatchBytes) now flushes as flushAt does, so a few large events go out before the queue starts dropping them. The file queue keeps each event's serialized size: measured when it is added, and read from the file sizes when a later process loads the queue. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * fix(desktop): feed flags the person properties beforeSend keeps $set/$set_once were stored for flag evaluation while the event was prepared, before the beforeSend callbacks ran, so a redacted value or a dropped event still reached the next /flags request. They are now taken from the event as it is queued. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * fix(desktop): keep properties beforeSend removes off the queued event The payload builder merged the common properties ($feature/<key>, $active_feature_flags, $recording_status, $lib) under every event again, so a property the callbacks removed came back. Every core path already builds them into the event's properties, so the payload adds nothing. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * perf(desktop): size the capture batch before reading queued events The flush peeked up to maxBatchSize events, decoding each one, before the 5 MiB batch cap picked the few it sends. With 8 MiB AI events queued that read far more than one request carries, on the UI isolate. The queue now applies the cap from its tracked per-event sizes before it reads an event, always keeping the first, so only the batch is decoded. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * fix(desktop): release delivered payloads after each capture v1 batch A flush that kept finding queued events held every delivered payload until it ended. Emit flush per batch so multi-megabyte AI events are released as soon as they are sent. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * fix(desktop): turn on person processing only for events beforeSend keeps Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * fix(desktop): give beforeSend a deep copy of the event properties Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * docs: limit the capture v1 migration note to native and desktop platforms Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * docs(desktop): note beforeSend cannot change $lib or $lib_version Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * fix(desktop): cap the response body read at 30 seconds A body that trickles in more often than the 10 s idle timeout reset it forever, holding the flush. The body now also fails after 30 s in total. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * fix(desktop): warn when captureAiMaxEventBytes is over the ceiling Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * style: format the merged fetch attempt Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * ci: update SDK compliance harness to 1.26.0 (#680) * ci: update SDK compliance harness to 1.25.0 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * chore(compliance): bump the test harness to 1.26.0 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com> * fix(desktop): check registered person processing before caching identify * fix(desktop): keep a legacy $set in properties for beforeSend to remove * fix(desktop): recompute person processing from the properties beforeSend keeps --------- Co-authored-by: Claude Opus 5.5 (1M context) <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.
💡 Motivation and Context
Update: moved to 1.26.0 (
c90b42db), the version the server SDK PRs use (e.g. PostHog/posthog-rs#317). 1.26.0 only changes thecapture_analytics_v1/capture_ai_v1suites, which this adapter doesn't run, so the counts below still hold.Stacked on #679 (
feat/v6-desktop-capture-ai). A harness maintainer asked the mobile capture v1 branches to move to the latest harness (PostHog/posthog-android#881 (comment)). This PR bumps the SDK compliance harness from 0.9.0 to 1.25.0:test-harness-version:0.9.0→1.26.027806196…(main, July) →c90b42dbe2235c89aad3b4dddf74f520a8c6c747(the1.26.0tag). Its inputs are the same as in July. The only change intest-sdk-action.ymlis theupload-artifactpin.sdk_compliance_adapter/docker-compose.ymlimage:0.9.0→1.26.0Why #679
#679 is the only open 6.0 branch that has both desktop capture v1 (#673, through the #678 merge) and
captureAi(#674). #673 has nocaptureAi, and #674 has no desktop capture v1. #679's adapter also already takes theoptionsparameter that #674 added to the platform interface.The adapter doesn't exercise either feature yet, though.
ComplianceAdapterreplacesPosthogFlutterPlatformInterface.instancewith its own_CompliancePlatform, which builds events and posts them to/batchitself. The harness tests the DartPosthog()facade and that adapter-side transport, not the desktop capture v1 client. The adapter declares onlycapture_v0andencoding_gzip, so at 1.25.0 it runs thecaptureandfeature_flagssuites (sdk-typeserver), the same as at 0.9.0. The bump is safe on any branch in this stack. I put it on #679 because a later change that drives the real desktop client through the adapter would go there.Capabilities
No new capabilities are declared. All the capabilities added in 1.24 and 1.25 only gate tests in the
capture_analytics_v1andcapture_ai_v1suites. Those suites needcapture_v1/capture_ai_v1, which this adapter can't honestly declare until it sends events through the SDK's own capture v1 transport.event_uuid_overridecapture/captureAitake no caller uuid.capture_ai_keeps_supplied_uuidis alsosdk_types: [server].bounded_retriesmax_retries_respectedin the v1 suites.disable_geoip/flagsdisable_geoiptests infeature_flagsaren't gated and still run.historical_migrationreported_drops/stateto show the SDK's per-eventdropresults, and the adapter doesn't see them.generated_payloads/capture_aisize tests. The adapter has no/capture_airoute.log_capturegenerated_payloadsincapture_ai_v1.property_layers/initsuper_propertiesandbefore_sendwired to the real SDK.fail_openphx_key handling, which the adapter skips.What changes for this adapter between 0.9.0 and 1.25.0:
capture.non_utc_event_timestamp_is_converted_to_utc(1.0.0) andfeature_flags.retry_behavior.retries_flags_on_502/retries_flags_on_504(0.10.0). The adapter already handles all three./flagstests that assertedperson_properties.distinct_id(0.9.1 relaxed that contract).💚 How did you test it?
I ran the adapter locally with
flutter test test/adapter_server_test.dart(Docker wasn't available) and ran the harness from source at each tag withposthog-test-harness run --sdk-type server:2169494c): 47 tests incapture+feature_flags, 47 passed, 0 failed.68498bcf, baseline): 45 tests, 45 passed, 0 failed.I didn't run the
ghcr.io/posthog/sdk-test-harness:1.25.0image locally. CI on this PR runs it.📝 Checklist
If releasing new changes
pnpm changesetto generate a changeset fileNo changeset: this is CI/test-harness only and ships nothing, the same as the 0.9.0 bump (#458).
🤖 Agent context
Autonomy: Human-driven (agent-assisted)
Claude Code (Opus) read the 0.9.1–1.25.0 release notes and the 1.25.0 contracts, compared the 6.0 branches' ancestry and adapter code to pick the base, and ran both harness versions against the local adapter.
Rejected: declaring
capture_v1/capture_ai_v1and the 1.24/1.25 capabilities in this PR. The adapter's events never go through the SDK's capture v1 transport, so passing those suites would only test the adapter's own code. Moving the adapter onto the real desktop client is a separate change.🤖 Generated with Claude Code