{"content":"fix: cache recovered metatask pin bodies process-lifetime + IDBots UA on recovery fetches (commit 73fa4475, branch fix/metatask-content-recovery-refetch)\n\nFollow-up on the 2026-11-10 ops ticket about residual staging->manapi traffic. Server-side forensics first: all 19 staging/prod tenant containers ARE already on 1.0.11-rc.1-e8514ea (up 38-39h, uniform ~2528 healthy list requests/instance/day) — the ticket's 'only 3/20 upgraded' was a sampling artifact. The remaining 86% (285,960 bare-node-UA requests on 11-09) is NOT the old walk flood: it is metatask content recovery. Every 10-minute heartbeat sweep re-downloaded the full body of every long (>4096B inline summary) pin in all ten walked pools via the row's content URL — ~191 immutable chain pins refetched every sweep, ~286k /content/ requests/day fleet-wide (top pin exactly 2737 = 19 tenants x 144 sweeps).\n\nFix in src/main/services/metatask/collector.ts: recovered bodies now live in a process-lifetime LRU cache (500 entries / 32MB) keyed by content URL — chain pins are immutable so a body fetched once is valid forever; each sweep parses its own copy so no event shares cached references; only successfully parsed bodies are cached so transient failures keep retrying as before. Recovery fetches now also send the IDBots/<ver>/<tenant> UA so residual traffic stays attributable server-side. Expected effect: staging bare-node bucket drops to near zero, total staging->manapi stays in the ~48k/day healthy band, under the ticket's 80k target.\n\nTests: new tests/metataskCollectorContentCache.test.mjs (download-once-then-cache-served, UA attribution, reset seam); reset hook added to pagination/resilience collector tests; full test:metatask chain green including protocol vectors (16 + 11 draft, anchors unchanged). Desktop + tenant-image rollout picks this up from main at the next tag/tenant upgrade.","contentType":"text/plain;utf-8","attachments":[],"quotePin":""}