Skip to content

fix(registry): bump updated-at to bust stale tarball caches (reach the #269 file manifest fix)#271

Merged
pawellisowski merged 1 commit into
mainfrom
fix/registry-index-bump-busts-stale-file-manifest
Jun 26, 2026
Merged

fix(registry): bump updated-at to bust stale tarball caches (reach the #269 file manifest fix)#271
pawellisowski merged 1 commit into
mainfrom
fix/registry-index-bump-busts-stale-file-manifest

Conversation

@pawellisowski

Copy link
Copy Markdown
Contributor

What

Bump registry-index.json updated-at (2026-06-18 → 2026-06-26). Data-only, one line.

Why

#269 flipped _core/file status: planned → available inside the rolling main.tar.gz but left registry-index.json unchanged. The agent-install tarball cache is keyed on Index::snapshot_fingerprint() (a hash of registry-index.json), so the key never rotated — users who cached main.tar.gz between #257 (06-18) and #269 (06-25) keep installing the stale file manifest (status: planned), and aware app run then rejects a runnable file/write node with E_APP_AGENT_UNAVAILABLE.

Bumping updated-at is the documented "manual refresh lever" (cli/src/registry/index.rs): it rotates the fingerprint so every stale tarball cache busts on the next install. The index is fetched live from main with a 1h TTL, so this propagates to all users within the hour — no binary release needed. After it lands, aware agent install file yields status: available.

This unblocks a downstream floless.app feature (steel-model BOM export nodes use file/write).

Verification

  • aware agent reindex --check → ✓ up to date (the catalog carries its own timestamp; the index bump doesn't stale it).
  • Mechanism confirmed by reading install/registry.rs:48-63 + registry/index.rs snapshot_fingerprint + registry/fetch.rs (live source raw.githubusercontent.com/.../main/registry-index.json, 1h TTL).
  • Empirically: purging the cache + reinstalling already yields status: available from fresh main; this bump achieves the same bust systematically.

Review note

Data-only registry refresh-lever bump (no code) — there is nothing for a code reviewer to assess; treating Codex review as N/A for this one-line operational change.

Refs #270 (the systemic fix: auto-bump on manifest change / TTL the tarball cache).

…#269 file manifest fix)

#269 changed `20-agents/_core/file/manifest.yaml` (status: planned → available) INSIDE the
rolling `main.tar.gz`, but did not touch `registry-index.json`. The agent-install tarball cache
is keyed on `Index::snapshot_fingerprint()` (a hash of registry-index.json), so a manifest change
that leaves the index unchanged never rotates the key — users who cached `main.tar.gz` between
#257 (2026-06-18) and #269 (2026-06-25) keep getting the STALE `file` manifest (status: planned).
`aware app run` then rejects an actually-runnable `file/write` node with E_APP_AGENT_UNAVAILABLE.

Bumping `updated-at` is the documented "manual refresh lever" (registry/index.rs): it rotates the
fingerprint so every stale tarball cache busts on the next install (index is fetched live from main
with a 1h TTL), and `file` installs as status: available. Data-only; `aware agent reindex --check`
stays green (the catalog carries its own timestamp). Systemic fix tracked separately.
@pawellisowski pawellisowski merged commit 79c46ac into main Jun 26, 2026
1 check failed
@pawellisowski pawellisowski deleted the fix/registry-index-bump-busts-stale-file-manifest branch June 26, 2026 07:11
pawellisowski added a commit that referenced this pull request Jun 26, 2026
…backs (#270)

Ships the residual tarball-cache staleness fixes merged since v0.81.0:
- #272 (#270): 1h TTL on the agent-install tarball cache so an in-archive manifest
  change that leaves registry-index.json byte-identical self-heals within an hour,
  with graceful fallback to a prior index-consistent cache on offline/corrupt/raced
  refreshes.
- #271: bump registry-index.json updated-at to bust warm caches for the #269 file agent.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant