fix(logs): keep pinned filters out of editable filterGroup#61008
Merged
DanielVisca merged 3 commits intoJun 1, 2026
Conversation
The person profile Logs tab pins a `distinct_id` filter so the tab can't fall back to project-wide logs. Previously this was achieved by merging the pinned filter into `filterGroup` (the user-editable state) and then hiding the resulting chip from the bar via a deep-equal check. That broke when the pinned filter's shape changed after initial mount — most commonly when `logsConfig.logs_distinct_id_attribute_key` resolves to a non-default key on a team with `posthogDistinctId` patched. The filterGroup was already merged with the OLD pinned filter, the dedup in `mergePinnedFilters` only compared against the NEW one, and the stale filter stuck around and rendered as a chip with an X. Clicking the X removed it from filterGroup but the query was still scoped via the hidden (new) pinned filter, so the page felt like "filter is still applied or something". Architectural fix: keep pinned filters entirely out of `filterGroup`. A new `queryFilterGroup` selector combines `filterGroup + pinnedFilters` only at query-build time. The data layer reads `queryFilterGroup` for payloads and subscribes to it for rerun triggers; the taxonomic value suggestion endpoint sees `queryFilterGroup` so suggestions stay scoped. Chips render only `filterGroup`, so a pinned filter can't appear there no matter how its shape evolves. Generated-By: PostHog Code Task-Id: a0cd1bfc-9b19-4b30-9123-6488d22b3f6a
When a team has patched `logs_distinct_id_attribute_key` away from the default `posthogDistinctId` (e.g. to `user.id` for backend services that emit logs under their own identifier), the Logs tab on a person profile now shows a small muted hint above the viewer: Scoped to this person via the `user.id` log attribute. Customised from default `posthogDistinctId`. Default-key teams see only the first sentence — no extra noise. The suffix appears only when the key differs, mirroring the experiments `SettingsTab` precedent (`text-muted text-xs` paragraph that conditionally appends "Customised from …" when the team has overridden a default). Closest precedent: products/error_tracking issue filters surface team-level quick-filter scope via a muted indicator; experiments CUPED settings tab appends "Default is set in …" only when the user hasn't explicitly set it. Generated-By: PostHog Code Task-Id: a0cd1bfc-9b19-4b30-9123-6488d22b3f6a
Contributor
|
Size Change: -4.52 kB (-0.01%) Total Size: 80.9 MB 📦 View Changed
ℹ️ View Unchanged
|
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
Contributor
|
Reviews (1): Last reviewed commit: "feat(logs): surface custom distinct_id a..." | Re-trigger Greptile |
Contributor
|
✅ Visual changes approved by @DanielVisca — baseline updated in 3 changed. |
3 updated Run: 2168fb5f-332c-4b80-9b71-2f7ceaf14fb8 Co-authored-by: DanielVisca <16750763+DanielVisca@users.noreply.github.com>
github-actions
Bot
dismissed
their stale review
New commits pushed (delta classified non_trivial_delta) — stamphog approval dismissed; re-review running automatically.
Contributor
|
🎭 Playwright report · View test results →
These issues are not necessarily caused by your changes. |
This was referenced Jun 2, 2026
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
1 participant
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
The Logs tab on the person profile pins a
distinct_idfilter so the tab can't fall back to project-wide logs. Until now this was implemented by merging the pinned filter intofilterGroup(the user-editable state) and then hiding the resulting chip via a deep-equal check inLogsFilterBar.That broke when the pinned filter's shape changed after initial mount — most commonly when
logsConfig.logs_distinct_id_attribute_keyresolves to a non-default key on a team that has patched it (e.g. touser.idfor backends that emit logs under their own identifier). On first render the pinned filter used the fallback defaultposthogDistinctId; once the team'slogs_configresolved, a new pinned filter was reconstructed with the custom key. The old pinned filter sat stale insidefilterGroup, the dedup inmergePinnedFiltersonly compared against the new one, and the leftover filter rendered as a chip with an X. Clicking the X removed it fromfilterGroupbut the (hidden) new pinned filter still scoped the query — so the page felt like "filter is still applied but I can't see why".Changes
Architectural fix — keep pinned filters entirely out of
filterGroup.logsViewerFiltersLogic.ts— newqueryFilterGroupselector combinesfilterGroup + pinnedFilterson demand. The reducer stays clean;afterMount/propsChangedonly mirrorpinnedFiltersinto state, never touchfilterGroup. OldmergePinnedFiltershelper replaced with a non-dedupingcombineWithPinnedFilterssince the dedup concern goes away once pinned filters never enter the editable reducer.logsViewerDataLogic.ts— query payloads (4 sites: query, fetchNextLogsPage, sparkline, liveTail) now readvalues.queryFilterGroup. Subscription switched fromfilterGroup→queryFilterGroupso the query reruns when pinned filters resolve.LogsFilterBar.tsx— removed the deep-equal hide-chip workaround entirely.endpointFilters(taxonomic value-suggestion endpoint) now passesqueryFilterGroupso suggestions stay scoped, while the editablefilterGroupis the source of truth for what chips render. Drops thefast-deep-equalimport.PersonLogsTab.tsx— small muted hint above the viewer surfaces which attribute key is in use; when the team has customised the key away fromposthogDistinctIdthe hint appends "Customised from default …". Pattern lifted fromfrontend/src/scenes/experiments/ExperimentView/SettingsTab.tsx:70–87.Net diff: 4 files, +52/-35 lines.
Precedent the new shape follows:
products/error_tracking/frontend/components/IssueFilters/issueFiltersLogic.ts:63,84— cleanfilterGroupreducer + derivedmergedFilterGroupselector used only by the query layer. Counter-example we explicitly moved away from:sessionRecordingsPlaylistLogic(merges pinned into the reducer, then subtracts pinned back out in atotalFiltersCountselector to undo the mess — exactly the leakiness this PR removes from the logs viewer).How did you test this code?
I'm an agent (PostHog Code / Claude Opus 4.7). The user verified manually in the local dev stack against a person with multiple distinct_ids on a team where
logs_distinct_id_attribute_keyhad been patched touser.id, confirming both:Automated checks:
tsc --noEmitclean on all three touched files (pre-existing TS errors in unrelated files only).logsViewerFiltersLogic.test.tssuite fails to parse on master too (Jest/Babel config issue, not introduced here); I did not add new tests because the pre-existing harness for this logic file is broken on master and fixing it is out of scope.The
logs_distinct_id_attribute_keyendpoint dual-registration on/api/projects/(which originally surfaced this bug class) lands separately via #60967 and is already on master.Automatic notifications
Docs update
No docs change. Customer-facing doc for the team-configurable attribute key lives in
docs/internal/logs-link-person.mdand was published as part of the original feature; this PR doesn't change observable behavior for the default-config majority.🤖 Agent context
PostHog Code (Claude Opus 4.7). The bug originally surfaced as a stale removable filter chip on the dev Logs tab that the local stack didn't reproduce, with the user pointing out the distinguishing variable was that they had PATCH'd
logs_distinct_id_attribute_keyon the dev team. Root-cause traced tomergePinnedFiltersdeduping only against the new pinned-filter content while old pinned-filter state remained infilterGroup. Two candidate fixes were considered: (1) tighten dedup to evict any filter matching the previous pinned key+type, (2) keep pinned filters entirely out offilterGroup. (2) was chosen because it makes the bug class structurally impossible, matches the existing precedent in error-tracking'sissueFiltersLogic, and removes the hide-chip workaround that (1) would still need to retain.Created with PostHog Code