The re-seed flow

Background reading: Postage batches and re-seeding.

TL;DR

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.