- Shipped
- August 21, 2026 at 2:02 AM UTC
- Author
- Kamo
- Commit
- f08b479
A Chats → Support row showed the same support glyph on every line, so a queue of them was a wall of identical blue circles. The face people actually scan for is whoever ASKED, so the row now carries the requestor's id, display name and photo. The photo is resolved here rather than left to the client, which is the whole difficulty: every other avatar in this feed is backfilled from the viewer's own organization directory, and a support requestor is — on the platform's desk — always somebody else's member, so that directory returns nothing for exactly the rows this is for. Two batched reads cover a page, in the same spirit as the visitor pre-fetch alongside them. The avatar row is re-read by id instead of being taken off member.getAvatar(): Avatar is a JOINED hierarchy and the association is lazy, so what that returns is a proxy of the BASE type. instanceof AvatarPhoto is false through it even after initialization, and every uploaded photo would be looked for at the Avatar Creator vector path. Loading by id gives the concrete subclass and its file extension. requestorIsAmbiguous is the case the glyph survives for, and it is one specific case rather than a hedge: an anonymous web-chat visitor has no member record, so the ticket names the org's SYSTEM member — the owner — as its requestor. Their photo would put the wrong person on the conversation, and on the platform's own marketing widget it would be the face of whoever is reading the list.