Repository navigation
Conversation
Generated with `pnpm generate-markdown-references` for posthog-js 1, posthog-node 5 and posthog-react-native 4, each with its latest page. posthog-node-6.md is generated from the capture-v1 branch (#5407) with `--major 6 --source`. It has no latest page, because 6.x is not released. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Contributor
|
Contributor
Coherence📄 0 spec file errors · ⛔ 0 broken rules · 🚪 1 unchecked input · 🐛 0 bugs that came back What is Coherence?Coherence compares the code with its spec files ( This check read 44 parts of the code and 7 rules. Note These findings do not make this check fail. None of these findings are in files that this pull request changes. You do not need to fix them in this pull request. 🚪 Unchecked inputs (1)
What this means and how to fix itInput from outside this code comes in at these places. The spec does not say what checks that input. 10 more places were already like this when Coherence was added. This list does not show them. To close one of these, find the place by its name in the
To get the line to add, run |
Contributor
Contributor
|
Size Change: 0 B Total Size: 26.5 MB ℹ️ View Unchanged
|
Contributor
Node SDK acceptance v2Commit: 7f04bf5 Capture v0✅ 83 passed / ❌ 4 non-passing / Drill-down: run artifacts → ❌ server_snapshot_payload_false — failed_assertionExpected native data result Code: Failed step: acceptance/public/evaluate-flags.feature:868 the public snapshot outcomes should have these semantics: ❌ server_snapshot_payload_zero — failed_assertionExpected native data result Code: Failed step: acceptance/public/evaluate-flags.feature:868 the public snapshot outcomes should have these semantics: ❌ server_snapshot_payload_null — failed_assertionExpected native data result Code: Failed step: acceptance/public/evaluate-flags.feature:868 the public snapshot outcomes should have these semantics: ❌ migration/yaml-parity-v1/remote-flags-v1.feature::Omitted GeoIP settings default to enabled in flag requests — failed_assertionFlags field differs Code: Failed step: migration/yaml-parity-v1/remote-flags-v1.feature:134 the first flags request field "geoip_disable" should equal JSON false Operation: Field: Expected: false Actual value: true Harness exit: 1; report validation exit: 1. Capture v1✅ 148 passed / ❌ 4 non-passing / Drill-down: run artifacts → ❌ server_snapshot_payload_false — failed_assertionExpected native data result Code: Failed step: acceptance/public/evaluate-flags.feature:868 the public snapshot outcomes should have these semantics: ❌ server_snapshot_payload_zero — failed_assertionExpected native data result Code: Failed step: acceptance/public/evaluate-flags.feature:868 the public snapshot outcomes should have these semantics: ❌ server_snapshot_payload_null — failed_assertionExpected native data result Code: Failed step: acceptance/public/evaluate-flags.feature:868 the public snapshot outcomes should have these semantics: ❌ migration/yaml-parity-v1/remote-flags-v1.feature::Omitted GeoIP settings default to enabled in flag requests — failed_assertionFlags field differs Code: Failed step: migration/yaml-parity-v1/remote-flags-v1.feature:134 the first flags request field "geoip_disable" should equal JSON false Operation: Field: Expected: false Actual value: true Harness exit: 1; report validation exit: 1. |
Contributor
SDK performance: posthog-nodeBenchmarks completed. No changes flagged for review. Flags require at least a 5% change in the median and all six pairs agreeing on direction. This is a noise filter, not proof of a performance change or a CI gate. View all results
Values are medians of paired measurements. Not flagged does not mean unchanged. Unavailable means a measurement could not be provided, not zero. Estimated allocation measurements retain their instrumentation uncertainty. RSS measures the whole process, not just SDK allocations; observed peaks are sampled checkpoints. Paired ranges in the diagnostics describe variability, not confidence intervals. Each shard uses its own runner; compare Before PR against With PR within a row, not across shards. Compared 102 metric rows; 102 rows shown in all results. Omitted or shortened data remain in |
This was referenced Nov 6, 2026
…ity maps Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2 of 12 tasks
| | <a id="samplerate"></a> `sampleRate?` | `number` | Session replay sample rate between 0 and 1 Local config has precedence over remote config when both are set. If undefined, sampling is controlled by remote config (when available). | | ||
| | <a id="screenshotcolormode"></a> `screenshotColorMode?` | `"ARGB_8888"` \| `"RGB_565"` | **`Experimental`** Experimental. Screenshot bitmap pixel format. ARGB_8888 preserves transparency and color precision. RGB_565 uses half the bitmap memory but reduces color precision and removes alpha, making transparent window regions appear black. Unsupported devices fall back to ARGB_8888. Android only. Requires `@posthog/react-native-plugin` 2.8.0 or later. **Default** `'ARGB_8888'` | | ||
| | <a id="screenshotcompressionquality"></a> `screenshotCompressionQuality?` | `number` | **`Experimental`** Experimental. WebP compression quality, clamped to 0–100. Fractional values are truncated. Higher values generally retain more detail and produce larger payloads. Compression is lossy, except at quality 100 on Android 10, which uses lossless WebP. Non-finite values use the native default. Does not change screenshot resolution. Android only. Requires `@posthog/react-native-plugin` 2.8.0 or later. **Default** `30` | | ||
| | <a id="screenshotmodebackgroundcapture"></a> `screenshotModeBackgroundCapture?` | `boolean` | Schedule screenshot image capture on a background queue. iOS only Experimental support Warning: Enabling this option will trigger Main Thread Checker warnings and may briefly freeze the app the first time a screenshot is captured. Consider disabling Main Thread Checker in your scheme's run diagnostics when enabling this. **Default** `false` | |
Contributor
There was a problem hiding this comment.
Contributor
Author
There was a problem hiding this comment.
This isn't going out until release and we'll regenerate!
Contributor
Author
There was a problem hiding this comment.
Yes, we'll regenerate from the latest. It also regenerates on every release, so any minor drift gets picked up then. Thanks!
…pinned sdk-specs - scripts/fetch-sdk-specs.sh fetches PostHog/sdk-specs at one pinned commit, which CI and the release both read. A change upstream can't stop a release or fail an unrelated PR. - CI and the release run `pnpm generate-markdown-references`. - check-public-api.js also checks the Markdown pages, so CI fails when a committed page is stale. Its diff buffer is larger, for the page diffs. - Regenerates the pages with the review fixes. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Contributor
Replay incident risk checkThis diff touches code involved in past incidents. This is a heads-up, not a verdict: read the matched sections of INCIDENTS.md and answer their review questions before merging. For a judgment on whether this diff has the same failure mode, run the |
7 tasks
eli-r-ph
reviewed
Nov 7, 2026
Contributor
There was a problem hiding this comment.
This page is generated from capture-v1 as it is today, and capture-v1 keeps changing until 6.0 ships (for example #5593 changes $lib handling and the migration guide). Can the 6.0 release regenerate it from the merged code so 6.x becomes the latest page? Once main is synced into capture-v1, the stale-page check will also fail capture-v1 PRs that edit Node doc comments until this page is regenerated.
Contributor
Author
There was a problem hiding this comment.
Yep, the 6.0 release regenerates it from the merged code, and 6.x becomes the latest page then. It already matches the latest capture-v1, and we can regenerate it again as capture-v1 changes.
Good catch on the check. capture-v1 still says 5.x, so the generator would have written 6.0 into the 5.x pages. It now reads the pending major changesets and writes the 6.x page instead, and the check covers that page. After the sync, capture-v1 PRs that change Node doc comments just need to regenerate it. Thanks!
A capture-v1 PR now regenerates posthog-node-6.md, so the check fails when it goes stale. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Contributor
📝 No Changeset FoundThis PR doesn't include a changeset. A changeset is required to release a new version. How to add a changesetRun this command and follow the prompts: pnpm changesetRemember: Never use |
…to docs/sdk-reference-pages
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…to docs/sdk-reference-pages
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
gewenyu99
marked this pull request as ready for review
November 10, 2026 19:36
gewenyu99
requested review from
eli-r-ph and
turnipdabeets
and removed request for
a team
November 10, 2026 19:36
PR overviewNo security issues were found in this pull request. Reviews
|
![posthog[bot]](https://avatars.githubusercontent.com/in/1203049?s=60&v=4){kind=small}
turnipdabeets
approved these changes
Nov 10, 2026
This branch has not been deployed
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.
Problem
We have a wave of breaking changes with new major versions for most SDKs. References are now read mostly by bots, not humans, and the HogRef format is heavy. Stacked on #5588.
Changes
posthog-js-1.md,posthog-node-5.mdandposthog-react-native-4.md, each with its latest page, under each package'sreferences/.posthog-node-6.md, generated fromcapture-v1(feat(node)!: posthog-node 6 on capture v1 (DO NOT MERGE) #5407) with--major 6 --source. It has no latest page, because 6.x is not released.scripts/fetch-sdk-specs.shfetches PostHog/sdk-specs at one pinned commit. CI and the release both use it, so an upstream change can't stop a release or fail an unrelated PR.pnpm generate-markdown-references.check-public-api.jsalso checks the Markdown pages, so CI fails when a committed page is stale.Tested: Regenerating at the pinned sdk-specs gives no diff, and
pnpm check:public-apipasses. After a Node doc comment edit and a regenerate,pnpm check:public-apiexits 1.Checklist
🤖 Agent context
Autonomy: Human-driven (agent-assisted)
Claude Code (Opus 5.5) built and opened it, directed by Vincent. Not yet reviewed line by line.
End result
This is what we're building toward: the reference page on posthog.com, rendered from this PR's Markdown in a local posthog.com build with a local Strapi.
Merge order
Parked: this stack ships with the posthog-node 6 release (#5407). It replaces #5565, #5566 and #5568.
🤖 Generated with Claude Code