- Navios
- 5 de agosto de 2026 às 01:43 UTC
- Autor
- Kamo
- Enviar
- a73117b
Um participante cuja foto está faltando no armazenamento mostrou um ícone de imagem quebrada para todos os outros na chamada, para sempre — nunca se degradava às iniciais. Upstream pode renderizar loadableAvatarUrl incondicionalmente porque esse valor é somente definido após o getFirstLoadableAvatarUrl() o pré-carregou com sucesso. Este garfo removido que garantia de ambos os lados: o middleware participantes define-o directamente a partir do JWT quando desactivar o terceiro pedido de terceiros (sem pré-carregamento), e mapStateToProps cai de volta para o avatarURL bruto. Então, um URL não validado agora atinge o componente. Quando o avatar vem de redux, em vez de um 'url' explícito, `useReduxLoadableAvatarURL` já é verdadeiro, então a configuração avatarFalhou não alteração `effectiveURL` — render produzido a mesma falha <img> novamente, e A StatelessAvatar só atinge seu ramo inicial quando o url é falso. Lembre-se de qual URL falhou e pule-o, então o retorno realmente acontece. Também redefinir o estado de falha quando loadableAvatarUrl muda, não apenas `url`. Encontrada através de um encontro real: uma foto de participante é gravada no DB (avatars.file hash, is active) mas o objeto não existe em MinIO, então **************************** retorna 404. 4 de 25 avatares de fotos ativos ficam órfãos dessa forma.