You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Return the local proxy when offline for Optimize-Storage assets
On-device log for #1118 revealed a second gap: with the network off,
both the PHImageManager (HighQualityFormat + networkAccessAllowed=YES)
primary path AND the PHAssetResource walker fail with
`NSURLErrorNotConnectedToInternet (-1009)`, because both are trying to
materialise the iCloud original. The user's caller then receives an
opaque -1009 with no image bytes — worse UX than Photos.app itself,
which happily displays the local downsampled proxy under Optimize
Storage. `AssetEntity.originFile` should degrade gracefully the same
way, not fail hard.
Add a tail fallback `fetchOfflineImageProxyFor:` that fires after both
the primary and walker terminal-fail. It issues one more PHImageManager
request with `deliveryMode=Opportunistic + networkAccessAllowed=NO`,
accepts the degraded result, and writes to a `proxy_`-prefixed
filename in the standard image cache directory. Callers get *something*
displayable offline; hitting the primary path online later still
materialises the iCloud original because `cachedPathForAsset:` does not
scan the `proxy_` prefix — no cross-mode pollution.
Also add an error log line inside the primary `dataHandler` so field
diagnostics can distinguish "PHImageManager errored with -1009" from
"PHImageManager returned no data" — the on-device log that surfaced
this offline gap was silent on which of the two triggered the walker
fallback.
Wired into both terminal-failure branches of `runWalker` — the
common case (PHImageManager primary → walker fallback → both fail) and
the RAW/exotic case (walker primary → PHImageManager fallback → both
fail).
Guard against double-reply from Opportunistic mode's multi-callback
contract with a `__block BOOL replied` — with networkAccessAllowed=NO
a second callback is unlikely, but PMResultHandler treats a second
reply as a programmer error.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
0 commit comments