Skip to content

ref(issues): Rename filterThreadInfo to getThreadInfo#113971

Merged
scttcper merged 6 commits intomasterfrom
scttcper/rename-thread-info
Apr 24, 2026
Merged

ref(issues): Rename filterThreadInfo to getThreadInfo#113971
scttcper merged 6 commits intomasterfrom
scttcper/rename-thread-info

Conversation

@scttcper
Copy link
Copy Markdown
Member

@scttcper scttcper commented Apr 24, 2026

No filtering takes place. Rename function + file to getThreadInfo.

While here:

  • use the existing getFileName util from debugMeta/utils instead of the local trimFilename copy (bonus: handles Windows paths)
  • inline getRelevantFrame into this file since this was the only caller
  • type the stacktrace properly so the any and the "this should not happen" fallback can go away, and use findLast for the in-app search

Stacked on #113946.

scttcper and others added 4 commits April 24, 2026 09:58
The thread selector kept a local `currentThread` state seeded from the
`activeThread` prop on mount and only updated it from `onChange`. When
navigating between events the prop changed but local state didn't, so
the "pin selected thread to top" logic looked up a stale id, got -1
back from findIndex, and the slice math produced a mangled list (last
thread missing at the front, others duplicated).

Drop the redundant state and key the memo off `activeThread` directly.
Guard the -1 case so a missing match just returns the sorted list.
Memoize `items` while here since it was rebuilding `<Option>` JSX on
every render.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
collapse the three useMemos into one, fold the asc/desc duplication in
the sort comparator into a direction multiplier, and pin the active
thread to the top in place instead of spreading a new array.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
the function derives info from a thread, it doesn't filter anything.
While here, use the existing getFileName util instead of a local copy,
inline the getRelevantFrame helper (only used here), and type the
stacktrace properly so the any and the "this should not happen"
fallback go away.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
@github-actions github-actions Bot added the Scope: Frontend Automatically applied to PRs that change frontend components label Apr 24, 2026
@scttcper scttcper marked this pull request as ready for review April 24, 2026 19:20
@scttcper scttcper requested a review from a team as a code owner April 24, 2026 19:20
@scttcper scttcper requested a review from a team April 24, 2026 19:20
the helper was only called once, and the `details` arg was unused when
the thread already had a name. inline it as a ternary so we skip the
getThreadInfo call entirely on the happy path.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Base automatically changed from scttcper/fix-thread-selector-order to master April 24, 2026 20:00
# Conflicts:
#	static/app/components/events/interfaces/threads/threadSelector/index.tsx
@scttcper scttcper enabled auto-merge (squash) April 24, 2026 21:51
@scttcper scttcper merged commit 902e4f1 into master Apr 24, 2026
64 checks passed
@scttcper scttcper deleted the scttcper/rename-thread-info branch April 24, 2026 21:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Scope: Frontend Automatically applied to PRs that change frontend components

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants