# The re-seed flow

Background reading: [Postage batches and re-seeding](../concepts/postage.md).

## TL;DR

```bash
bee-check <ref> --reseed --stamp <batch-id> --bee https://my-bee.example
```

`--reseed` requires `--stamp`. `--reseed` runs against the **first**
`--bee` URL — no multi-vantage re-seeding (it would be wasted API
calls; re-seeding is a write, not a probe).

## What happens, step by step

1. **Multi-vantage probe** runs first. You see the same vantages
   table you'd see without `--reseed`.
2. **Pre-flight stamp check** via `GET /stamps/{batch-id}` on the
   target Bee.
   - Refuses to proceed if the batch:
     - isn't known to this Bee (`exists: false`)
     - isn't usable yet (`usable: false` — chain still confirming)
   - Warns (but proceeds) if TTL is below 24h.
3. **Re-upload** via `PUT /stewardship/{ref}` with header
   `swarm-postage-batch-id: <batch-id>`.

If step 2 refuses, exit code is non-zero and the re-upload is
skipped.

## Reading the output

A successful re-seed prints, after the probe table:

```
re-seed:
  batch     a1b2c3...d4e5
  status    OK
  warnings  (none)
```

A refused re-seed:

```
re-seed:
  batch     a1b2c3...d4e5
  status    refused
  warnings:
    - batch not usable yet (chain may be syncing)
```

## Practical notes

- **Have the batch ready before you run.** `--stamp` doesn't buy a
  batch; it uses an existing one. Use `swarm-cli stamp buy` or your
  Bee's `/stamps` endpoint to provision one.
- **Re-seeding doesn't relocate content.** Bee re-fetches chunks
  during the upload; if no peer has them and your local store
  doesn't either, the operation will leave gaps.
- **Don't re-seed deferred uploads that haven't pushed yet.** First
  push them (`POST /chunks` cycle) — re-seed is for *refreshing
  stamps on already-network-resident content*.
- **Idempotent on the input side.** Running `--reseed` against the
  same ref + batch twice doesn't double-charge the batch; Bee
  recognizes already-stamped chunks.
