Summary
Downloading certain files from old (pre‑v8) buckets fails because one or more of their data blocks are no longer available on the gateway — the gateway returns S3 error (Gone) / block unavailable (exhausted bounded fetch) (HTTP 410). The app then appears to enter offline mode and/or presents the file as possibly corrupt, instead of clearly reporting that the file's data is unavailable on the server.
This is not related to the in‑progress v8 bucket migration (v8 only unblocks new uploads; it cannot resurrect already‑lost block data). Filing separately so it does not block the v8 work.
Observed (on‑device E2E, 2026‑06‑08, app v1.11.4, account ehsan6sha)
- Opened videos category, tried to download a video (
Hailuo_Video_…) → download failed; the UI behaved as if offline / the file were corrupt ("it downloads in offline mode").
- logcat (PID‑scoped):
ShelfService.ensureLocalThumbnail(758cd218-…): FulaApiException: Failed to download object:
AnyhowException(S3 error (Gone): Core error: block store error:
block unavailable (exhausted bounded fetch): bafyreihzgxnaqxeahuq77aqd5t46mlwq53qmiguyksn6sfrcsok5fu)
- Same class also seen on shelf metadata sync (upload):
ShelfStorageService.syncToCloud: Failed to upload object:
AnyhowException(S3 error (Gone): … block unavailable (exhausted bounded fetch): bafyrei…)
Root cause (server‑side — gateway / fula-api)
The referenced blocks have no holder on the gateway (genuinely lost / never fully replicated), so the gateway's bounded read exhausts and returns 410 Gone. This is the lost‑block / unreplicated‑backlog data‑availability problem tracked on the gateway side (see functionland/fula-api local‑retain + 410 work). Recovery of already‑lost bytes, if possible, is server‑side and out of scope for the app.
App‑side findings (this repo)
Even though the gateway now correctly returns 410 (a 4xx the SDK health‑gate is designed to ignore so a single bad file does not flip the app offline), the app still degraded the download UX to "offline" / "corrupt". Two improvements:
- Clear per‑file messaging. A
410 / block unavailable for one object should surface a specific "this file's data is unavailable on the server" message — not a global offline state and not a "corrupt file" impression.
- Verify the download path's offline‑fallback. Confirm the per‑download offline fallback is not separately flipping the UX to offline on a 410 (the SDK health‑gate ignores 4xx, but the app's download code may have its own fallback).
Scope / priority
- Old (pre‑v8) buckets only; not a regression from the v8 migration work.
- Server‑side data‑availability is tracked in
functionland/fula-api.
- App‑side ask: graceful 410 handling + clear "data unavailable" messaging (no false "offline"/"corrupt").
Filed from an on‑device E2E while validating the v8 migration (flag‑off parity phase).
Summary
Downloading certain files from old (pre‑v8) buckets fails because one or more of their data blocks are no longer available on the gateway — the gateway returns
S3 error (Gone)/block unavailable (exhausted bounded fetch)(HTTP 410). The app then appears to enter offline mode and/or presents the file as possibly corrupt, instead of clearly reporting that the file's data is unavailable on the server.This is not related to the in‑progress v8 bucket migration (v8 only unblocks new uploads; it cannot resurrect already‑lost block data). Filing separately so it does not block the v8 work.
Observed (on‑device E2E, 2026‑06‑08, app v1.11.4, account ehsan6sha)
Hailuo_Video_…) → download failed; the UI behaved as if offline / the file were corrupt ("it downloads in offline mode").Root cause (server‑side — gateway / fula-api)
The referenced blocks have no holder on the gateway (genuinely lost / never fully replicated), so the gateway's bounded read exhausts and returns 410 Gone. This is the lost‑block / unreplicated‑backlog data‑availability problem tracked on the gateway side (see
functionland/fula-apilocal‑retain + 410 work). Recovery of already‑lost bytes, if possible, is server‑side and out of scope for the app.App‑side findings (this repo)
Even though the gateway now correctly returns 410 (a 4xx the SDK health‑gate is designed to ignore so a single bad file does not flip the app offline), the app still degraded the download UX to "offline" / "corrupt". Two improvements:
410 / block unavailablefor one object should surface a specific "this file's data is unavailable on the server" message — not a global offline state and not a "corrupt file" impression.Scope / priority
functionland/fula-api.Filed from an on‑device E2E while validating the v8 migration (flag‑off parity phase).