fix(issues): render custom avatars in issue stream assignee column#115541
Closed
sentry-junior[bot] wants to merge 2 commits into
Closed
fix(issues): render custom avatars in issue stream assignee column#115541sentry-junior[bot] wants to merge 2 commits into
sentry-junior[bot] wants to merge 2 commits into
Conversation
The assignee column in the issue feed always rendered letter avatars because AssigneeBadge used ActorAvatar with the sparse Actor object (id, name, type) which lacks avatar data. Meanwhile, the People section on issue details rendered real avatars because it had full User objects. The member list with full User objects (including avatar info) was already fetched and passed to AssigneeSelector but never used for avatar rendering. This change: - Resolves the assigned user from the existing memberList in AssigneeSelector via a memoized Map lookup - Passes the resolved user to AssigneeBadge as an optional assignedUser prop - Renders UserAvatar (which supports uploaded/gravatar) when a full user is available, falling back to ActorAvatar for teams and users not in the member list No new API calls or serializer changes required.
github-actions
Bot
added
the
Scope: Frontend
Contributor
📊 Type Coverage Diff✅ No new type safety issues introduced. Coverage: 93.51% |
souredoutlook
added
the
Trigger: getsentry tests
natemoo-re
added a commit
that referenced
this pull request
May 14, 2026
Custom user avatars (uploaded / gravatar) did not render in the assignee column of the issues feed. `ActorAvatar` already handles `AsyncMemberAvatar` internally, but we have an opt-out mechanism when `actor.name || actor.email` exists, which happens in the issues feed. This PR simplifies that bypass and updates the `useMembers` hook to scan the query cache for users that may already have been fetched as sets it as `initialData`. This allows the `AsyncMemberAvatar` to render the full avatar if it's already been fetched or fallback to the current behavior if not. **Net result** The issues feed now has user avatars as expected. Closes #115541. --------- Co-authored-by: Claude Opus 4.6 <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
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
Custom avatars (uploaded / gravatar) never render in the assignee column of the issue feed — every assignee shows a letter avatar. Meanwhile, the People context pane on the issue details page renders them correctly.
Root Cause
Two compounding issues:
ActorSerializerreturns a sparse{id, name, type, email?}object forgroup.assignedTo— no avatar data.AssigneeBadge→ActorAvatar→AsyncMemberAvatarcheckscanRenderActor = Boolean(actor.name)→ alwaystrue→ skips user fetch → falls back toletter_avatar. EvenUserAvatar.isActor()treats anyActor-shaped object as letter-avatar-only.The key insight: the full
User[]member list with avatar data is already fetched inoverview.tsxand threaded all the way down toAssigneeSelector— it was just never used for the avatar render.Fix
assigneeSelector.tsx: Builds a memoizedMap<id, User>from the already-availablecurrentMemberListand resolves the assigned user whenassignedTo.type === 'user'.assigneeBadge.tsx: New optionalassignedUser?: AvatarUserprop. When provided and actor type is'user', rendersUserAvatar(which respectsavatar.avatarTypefor uploaded/gravatar) instead ofActorAvatar.What This Covers