#1435: A texture that loaded earlier is retried, not marked missing, when a re-fetch fails #1452
No reviewers
Labels
No labels
amd
avatars
bug
builder
cannot-reproduce
crash
epic
feature
from-viewer
gl-removal
known-limitation
monitoring
parity
perf
platform
priority
critical
priority
high
priority
low
priority
medium
provenance
rendering
rt
status
in-progress
status
testing
status
up-next
triage
ui
upstream
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
sky_line/Slipstream!1452
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "TheSlowly/Slipstream:texture-403-1435"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Fixes #1435.
A texture that loaded earlier in the session is no longer marked missing (drawn white) when a later re-fetch fails, e.g. the asset CDN's 403 after a low-memory downrez dropped every copy. It retries after 5 s, 15 s, 60 s, then every 5 minutes with a fresh request. Textures that never loaded, server bakes, map tiles and local files keep the old rule. The policy is a small header with a standalone check; a source check covers the wiring in
llviewertexture.cpp.Under low system memory the viewer emergency-downrezzes textures it thinks are off screen, dropping every copy. When it later asks for one again, the asset CDN can answer 403 for a texture it served minutes earlier. The fetch then "fails harder", and because no image is left the texture was marked missing and drew white for the rest of the session -- seen on a worn HUD after the first-run pipeline compile. A texture that delivered data earlier this session exists (asset ids are immutable), so a failed re-fetch now waits 5 s, 15 s, 60 s, then every 5 minutes, and asks again with a fresh request (which looks up the texture's address again). The policy lives in lltexturerefetchpolicy.h so it is tested standalone. Textures that never delivered data, server bakes, map tiles and local files keep the old rule. Test-Plan: g++ -std=c++20 -Wall -Wextra -Werror -I indra/newview \ indra/newview/tests/texture_refetch_policy_checks.cpp -o /tmp/t && /tmp/t (the policy: only regular textures that loaded are kept; the delay ladder; the request gate) python3 indra/newview/tests/texture_refetch_checks.py (llviewertexture.cpp: data arrival remembers the texture, the no-data failure asks the policy before setIsMissingAsset, updateFetch holds new requests until the retry time) clang-cl /Zs of llviewertexture.cpp with the Windows build's flags In world: hard to force a CDN 403. Under memory pressure (or after one), a HUD that loaded must not turn white; the log shows "Re-fetch failed (...); the texture loaded earlier, retrying in 5 s" instead of "Marking image as missing", and the face comes back. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>View command line instructions
Checkout
From your project repository, check out a new branch and test the changes.