## TL;DR
Stop waiting on an inventory as if it were a quick lookup. Vault inventories are asynchronous jobs that can take hours, so initiate the inventory well before the restore test window, persist its job id in the run store, and poll it on a slow schedule with the test marked as waiting rather than failed. Keep and reuse the last completed inventory while a fresh one runs, select the archive from that inventory, and only start the retrieval clock once the archive identity is confirmed.

```text
agent timed out waiting for glacier vault inventory and the restore test failed
```

## Use this when
- A restore test from an archive tier fails with a timeout while waiting for the vault inventory to be ready.
- The agent re-requests an inventory on every retry, resetting or duplicating the wait.
- Archive restores are reported unreliable even though retrievals succeed when run manually over a longer window.

## Not for this skill when
- The archive object itself is missing from a completed inventory.
- A standard or instant retrieval tier object is slow for a storage performance reason.

## Steps
1. Start the inventory before the test window. When a restore test is scheduled against an archive vault, initiate the inventory job at scheduling time or at the previous run close, not at test start, and store the job id, vault name, and initiation time in the run record. If an inventory job is already in progress for that vault, attach to it instead of starting another. Verify: at test start the run record already holds an inventory job id or a completed inventory
2. Poll slowly with a persisted state machine. Model the wait as explicit states, inventory requested, inventory ready, retrieval requested, retrieval ready, restoring, with each state and its entry time persisted. Poll at intervals measured in tens of minutes with jitter, update the state on each poll, and set the overall deadline for the inventory phase in hours, aligned to the service behaviour for the vault size. Verify: a run can be inspected mid-wait and shows its state, last poll, and next poll time
3. Never mark waiting as failed. While the inventory is pending inside its deadline, the test status is waiting, the orchestrator heartbeat keeps running from the polling loop, and no failure alert fires. Only a job reported failed by the service, or a deadline genuinely exceeded, converts the test to failed, and that report must include how long it waited. Verify: a test whose inventory takes three hours shows waiting throughout and no failure notification
4. Reuse the last good inventory. Cache the most recent completed inventory with its timestamp and use it to select archives for tests when a fresh inventory is still running, flagging selections as based on an inventory of that age. Archives are immutable once written, so a recent inventory is a sound selection source for restore testing. Verify: a test can proceed to retrieval using the cached inventory while a refresh runs in the background
5. Confirm the archive before starting retrieval. Once the inventory is ready, match the wanted archive by id, size, and creation time against the backup catalog record, and stop with a clear catalog mismatch if they differ, rather than retrieving the wrong archive slowly. Record the matched archive id in the checkpoint. Verify: the retrieval request references the archive id taken from the inventory, not only a description string
6. Budget the whole test realistically and report the phases. Publish expected durations per phase when the test is scheduled, track actual time per phase, and alert on phase overruns rather than one opaque total timeout. Feed the observed inventory durations back into scheduling so archive tests get windows that can actually contain them. Verify: the final report breaks out inventory, retrieval, and restore times separately

## Why it happens
Archive tiers trade speed for cost, and their inventory is a periodic snapshot produced by a background job, not a live listing. Agent harnesses built around fast object storage assume listing is instant, apply a normal request timeout, and then retry in ways that multiply inventory jobs. The failure is a mismatch of time models. Persisting the job and polling it on its own timescale aligns the harness with how the archive service actually works.

## Variants and edge cases
Edge cases: very large vaults can take far longer than small ones, so a single deadline will misfire at one end; scale the deadline by vault size or archive count from observed history. An inventory is a snapshot, so an archive written after it started will not appear; tests for very recent backups must wait for the next inventory or use a different tier copy. If the service expires inventory output after a window, download and store it promptly once ready.

### glacier restore test timed out on inventory
Use when the wait phase is the failure. Convert the wait into a persisted polling state before lengthening any timeout.

### agent requested a new vault inventory on every retry
Use when retries reset progress. Attach to the existing job id stored in the run record.

### archive restore works manually but fails in automated tests
Use when the manual run simply waited longer. Schedule the inventory at test scheduling time, not at test start.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_2v4TmEKtdVZ33BxwIIjQRQ