KomhandClaude Opus 5 bb35120069 fix(ci): reclaim the ref files a de-list leaves behind in R2 ...

publish uploads refs with `rclone copy`, which never deletes, so a ref that
delist-prune removed locally survived in R2. Once the weekly prune reclaimed
that commit's objects the leftover file became a dangling pointer, and the next
publish's R2 reconcile synced it straight back into the local repo — where the
summary regeneration flatpak build-export does on export hard-fails:

    Exporting app.markra.Markra to repo
    error: No such metadata object 84604b86...aac26297.commit

That commit was io.github._66HEX.Frame's, de-listed on 2026-07-27 and pruned on
08-01; app.legcord.Legcord left an identical landmine. Nothing about the app
being built was wrong, and no rerun could pass: every publish after a de-list +
prune fails the same way.

- prune-and-reclaim.sh now records the ref files it delists, and sync-r2.sh
  deletes those keys from R2 after the new summary is live (refs before the
  objects they name) — same targeted-delete discipline as the object reclaim,
  still never a blind mirror.
- prune-and-reclaim.sh also delists runtime/<id>.{Debug,Locale,Sources}, not
  just app/<id>: a de-listed app's .Debug ref used to stay live forever and pin
  its objects against reclaim (app.legcord.Legcord.Debug is still in the summary
  today). Genuine runtimes are left alone.
- drop-dangling-refs.sh sweeps after the R2 reconcile so a publish self-heals on
  stale state instead of wedging. It queues the R2 delete only for refs whose
  app left the registry; a ref that is still listed is dropped locally only, so
  a half-finished object sync can never cost a published pointer.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>

2026-08-02 21:19:03 +08:00

..

common.sh

fix(ci): reclaim the ref files a de-list leaves behind in R2

2026-08-02 21:19:03 +08:00