Bug: Migration step 06 fails on incomplete stamp metadata, causing total data loss
Maintainers usually reply within 2 days
@gacevicljubisa is already working on this.
Since Sep 22, 2025.
Assessment
This issue has not been assessed yet.
Description
Summary
Migration step 06 can fail during upgrade to 2.6.0+ when any chunk lacks complete postage stamp metadata, leaving the database in an inconsistent state where all chunks become unreachable despite remaining in storage.
Expected Behavior
- Migration should handle missing or incomplete stamp metadata gracefully
- Failed migration should not leave database in broken state
- Users should be warned about potential data issues before migration runs
- Rollback mechanism should exist for failed migrations
Current Behavior
Migration fails with recommendation to "nuke" the database when:
- Any
BatchRadiusItemV1chunk cannot compute stampHash chunkstamp.LoadWithBatchID()fails for any chunk- Database left with deleted old indexes but no new indexes created
- All data becomes unreachable (both pinned and regular chunks)
Root Cause
Migration step 06 (pkg/storer/migration/step_06.go:112-118) uses atomic approach:
stamp, err := chunkstamp.LoadWithBatchID(idxStore, "reserve", batchRadiusItemV1.Address, batchRadiusItemV1.BatchID)
if err != nil {
return err // MIGRATION FAILS - database inconsistent
}
// Old item already deleted at line 122, new item creation fails
The migration deletes old schema items before ensuring new schema items can be created successfully.
Steps to Reproduce
- Run bee node with incomplete stamp metadata (common in older versions)
- Upgrade to 2.6.0+
- Migration step 06 fails on first chunk with missing stamp data
- Observe error: "It's recommended that the nuke cmd is run to reset the node"
- Verify chunks exist in storage but cannot be retrieved via any API
Impact
- Critical: Total data loss requiring database reset
- Affects: Nodes upgrading from pre-2.6.0 versions
- User experience: Forced to choose between upgrade and data preservation
Proposed Solutions
Option 1: Graceful Degradation
- Skip chunks with missing stamp metadata during migration
- Log warnings for problematic chunks
- Allow migration to complete with partial data
Option 2: Two-Phase Migration
- Phase 1: Validate all chunks can be migrated successfully
- Phase 2: Only proceed with atomic migration if Phase 1 succeeds
- Provide clear error reporting on validation failures
Option 3: Stamp Reconstruction
- Attempt to reconstruct missing stamp metadata from available data
- Use chunk content and batch information to rebuild stamps
- Fall back to graceful degradation if reconstruction fails
Required Changes
- Modify
pkg/storer/migration/step_06.gomigration logic - Add pre-migration validation checks
- Improve error handling and rollback mechanisms
- Update migration failure messaging with recovery options
- Add telemetry to track migration success rates
Additional Context
This issue has caused recurring data loss during bee upgrades, particularly affecting nodes with customer data where database reset is not acceptable. The current "nuke database" recommendation is inadequate for production deployments.
Related Issues
- Pin eviction protection issue (chunks lost due to eviction) #5215
- Migration should coordinate with pinning system to prioritize preserving pinned data
- Dominant language
- Go
- Stars
- 1.5k
- Forks
- 390
- Avg merge
- 2d 11h
- Merged PRs (30d)
- 23
Getting set up
- Ships a Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from ethersphere/bee
-
Chequebook deployment uses a fixed 175,000 gas limit; it needs about 630,000 under Glamsterdam (live on Sepolia since 2026-10-06)Possibly taken @sbackend123 claimed this 10 days ago. Open
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
ethersphere/bee#5650 · 1 assignee ·
Maintainers usually reply within 2 days
-
Add a transaction inbox for outbound chain transactionsPossibly taken @sbackend123 claimed this 4 days ago. Openseen
Difficulty 5/5 Over a week Newbie friendliness 35/100
ethersphere/bee#5660 · 1 assignee ·
Maintainers usually reply within 2 days
-
Difficulty 4/5 3-5 days Newbie friendliness 45/100
ethersphere/bee#5659 ·
Maintainers usually reply within 2 days
-
accepted seen
Difficulty 4/5 3-5 days Newbie friendliness 40/100
ethersphere/bee#5648 · 1 comment ·
Maintainers usually reply within 2 days
-
pusher: chunksWorker deadlocks on a deferred chunk that fails IdentityAddress (send on nil op.Err), halting all push-syncPossibly taken @sbackend123 claimed this 12 days ago. Openseen
Difficulty 3/5 1-2 days Newbie friendliness 75/100
ethersphere/bee#5641 · 1 assignee ·
Maintainers usually reply within 2 days
Similar issues
-
agent-butler-finding chore
Difficulty 1/5 Under an hour Newbie friendliness 90/100
jordansmall/spindrift#5575 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
open-telemetry/opentelemetry-go-compile-instrumentation#1512 ·
Maintainers usually reply within 3 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
JakeChampion/lang#12684 ·
Maintainers usually reply within 1 day
-
goose sub-agent runs are never indexed: blame finds no session for any file a `delegate` child wroteOpenbug
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
C-bug O-community X-blathers-triaged
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
cockroachdb/cockroach#176150 · 1 comment ·
Maintainers usually reply within 12 days