Bug: Migration step 06 fails on incomplete stamp metadata, causing total data loss
Los mantenedores suelen responder en 2 días
@gacevicljubisa ya está trabajando en esto.
Desde el 22/9/2025.
Evaluación
Este issue todavía no se ha evaluado.
Descripción
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
- Lenguaje dominante
- Go
- Estrellas
- 1.5k
- Forks
- 390
- Merge medio
- 2 d 23 h
- PR fusionados (30 d)
- 24
Preparar el entorno
- Incluye un Dockerfile o un archivo de Docker Compose
- Tiene una plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de 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)Posiblemente ocupada @sbackend123 la tomó hace 16 días. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 85/100
ethersphere/bee#5650 · 1 asignado ·
Los mantenedores suelen responder en 2 días
-
Dificultad 4/5 3-5 días Aptitud para principiantes 48/100
ethersphere/bee#5666 ·
Los mantenedores suelen responder en 2 días
-
Add a transaction inbox for outbound chain transactionsPosiblemente ocupada @sbackend123 la tomó hace 10 días. Abiertoseen
Dificultad 5/5 Más de una semana Aptitud para principiantes 35/100
ethersphere/bee#5660 · 1 asignado ·
Los mantenedores suelen responder en 2 días
-
Dificultad 4/5 3-5 días Aptitud para principiantes 45/100
ethersphere/bee#5659 · 6 comentarios ·
Los mantenedores suelen responder en 2 días
-
accepted seen
Dificultad 4/5 3-5 días Aptitud para principiantes 40/100
ethersphere/bee#5648 · 1 comentario ·
Los mantenedores suelen responder en 2 días
Todos los issues de ethersphere/bee
Issues similares
-
Project submission:Abierto
Dificultad 1/5 Menos de una hora Aptitud para principiantes 72/100
slavakurilyak/awesome-ai-agents#845 ·
Los mantenedores suelen responder en 1 día
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
Los mantenedores suelen responder en 3 días
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 85/100
-
[BUG] deploy.restart_policy without condition drops the restart policyPosiblemente ocupada @akshat-lakhera la tomó hace 1 día. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
docker/compose#14383 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 72/100
Azure/azure-storage-fuse#2429 ·
Los mantenedores suelen responder en 1 día