ipfs/kubo · error

syncing deletes: %w

Error message

syncing deletes: %w

What it means

After deleting stale DHT value records, deleteStaleDHTValueRecords calls ds.Sync(ctx, datastore.NewKey("/")) to flush deletes to stable storage; failure is wrapped as 'syncing deletes'. The deletes may not be durable yet even though the batch committed.

Source

Thrown at core/node/storage.go:250

		}
		count++
		pending++
		if pending >= purgeBatchSize {
			if err := batch.Commit(ctx); err != nil {
				return count, fmt.Errorf("committing delete batch: %w", err)
			}
			batch = nil
			pending = 0
		}
	}
	if pending > 0 {
		if err := batch.Commit(ctx); err != nil {
			return count, fmt.Errorf("committing delete batch: %w", err)
		}
	}
	if count > 0 {
		if err := ds.Sync(ctx, datastore.NewKey("/")); err != nil {
			return count, fmt.Errorf("syncing deletes: %w", err)
		}
	}
	return count, nil
}

// isStaleDHTValueRecordKey reports whether key is a pre-v0.42.0 DHT value
// record: a single root-level path component that base32-decodes to a routing
// key in one of the DHT value namespaces. Everything else in the datastore
// (blocks, pins, MFS root, namespaced post-v0.42.0 records, IPNS publisher
// records, ...) lives under multi-component paths or does not decode to a
// namespaced routing key, so it never matches.
func isStaleDHTValueRecordKey(key string) bool {
	if len(key) < 2 || key[0] != '/' || strings.IndexByte(key[1:], '/') != -1 {
		return false
	}
	decoded, err := oldDHTValueBase32.DecodeString(key[1:])
	if err != nil {
		return false

View on GitHub (pinned to 329838acdf)

Solutions

  1. Inspect the wrapped error for I/O problems (dmesg / disk SMART) and fix underlying storage
  2. Verify the datastore implementation supports Sync; for flatfs/levelds ensure version is current
  3. Re-run the purge after storage recovers; deletes are idempotent
  4. If a custom datastore cannot support Sync semantics, switch to a supported one (flatfs, pebble)
Defensive patterns

Strategy: retry

Validate before calling

// verify backing store supports Sync and media is writable
if _, err := os.Stat(repoPath + "/datastore"); err != nil { return err }

Try / catch

for attempt := 0; attempt < 3; attempt++ {
    count, err = purgeStaleDHTValueRecords(ctx)
    if err == nil || !isTransientIO(err) { break }
    time.Sleep(time.Second * time.Duration(attempt+1))
}

Prevention

When it happens

Trigger: batch.Commit succeeded (count > 0) but the datastore's Sync on the root key fails — typically an fsync/disk I/O error, unsupported Sync on the backing store, or the datastore being closed mid-migration.

Common situations: Failing/ro remounted disk during a v0.42 migration, network filesystems where fsync fails, or a custom datastore implementation returning errors from Sync.

Related errors


AI-assisted analysis of ipfs/kubo@329838acdf (2026-09-03). Data as JSON: /api/errors/d6c43817081bced2. Report an issue: GitHub.