Research Review: Pushsync Silent Chunk Loss
I maintainer di solito rispondono entro 2 giorni
Valutazione
Questa issue non è ancora stata valutata.
Descrizione
PR: https://github.com/ethersphere/bee/pull/5390
Branch: fix/pushsync-out-of-depth-chunk-loss
Summary
Chunks can silently disappear from the network after a successful upload. Three bugs in the pushsync/pusher pipeline allow a chunk to be "delivered" (from the origin's perspective) while no node in the correct neighborhood actually retains it. The proposed fixes change protocol-level forwarding and receipt handling behavior.
Note: These issues are reproducible in smaller clusters such as the public testnet, where limited neighborhood sizes make out-of-depth forwarding and shallow receipts more likely.
Bug 1: Out-of-Depth Storing
Problem: When a node has no closer peer (ErrWantSelf) but the chunk is outside its AOR, it stores the chunk anyway. The chunk lands in a low-proximity bin, unreserve() evicts it immediately, but the origin already has a valid receipt. Chunk is gone.
Fix: Guard with proximity(chunk, self) < rad before storing — return ErrOutOfDepthStoring instead, origin retries with next peer. (pkg/pushsync/pushsync.go:301-309)
Doubling concern (@martinconic): The check uses StorageRadius() which already accounts for doubling (CommittedDepth - doublings). Using CommittedDepth instead would incorrectly reject chunks in sister neighborhoods. Appears correct, but needs research validation for edge cases during radius transitions.
Bug 2: Shallow Receipt Short-Circuits Parallel Pushes
Problem: On any shallow receipt, pushToClosest returns immediately with ErrShallowReceipt, discarding results from other inflight multiplex pushes (up to 32). Only 1 attempt of the error budget is used. Valid receipts from parallel pushes are thrown away.
Fix: Treat shallow receipt like any other peer failure — cache it, burn the budget, wait for inflight pushes. Only return ErrShallowReceipt after the full budget is exhausted or when falling back to ErrWantSelf. (pkg/pushsync/pushsync.go:369-530)
Bug 3: False ChunkSynced After Retry Exhaustion
Problem: After 6 pusher retries, chunks are marked ChunkSynced even though no node in the correct neighborhood stored them. The upload appears complete but the chunk is lost.
Fix: Report ChunkCouldNotSync instead of ChunkSynced. (pkg/pusher/pusher.go:283-289)
Gap identified (@martinconic): upload.Report() tag switch (pkg/storer/internal/upload/uploadstore.go:609-617) doesn't handle ChunkCouldNotSync — chunk gets cleaned up from the upload store but tag counters are never updated. Uploads with undeliverable chunks will show permanently incomplete sync counts.
Possible approaches:
- A. Add
ChunkCouldNotSynccase with a newFailedcounter inTagItem+ surface via API - B. Keep chunk in push queue for later retry (risk: infinite loops for undeliverable chunks)
- C. Surface via metrics/API only, accept the tag gap
Protocol Impact
| Scenario | Before | After |
|---|---|---|
| Node outside AOR, no closer peer | Stores + sends receipt (evicted shortly after) | Returns error, origin retries |
| Shallow receipt during multiplex | Immediate abort, 1 of 32 attempts used | Full budget exhausted before giving up |
| Pusher exhausts 6 retries | Marked ChunkSynced (false positive) |
Marked ChunkCouldNotSync (correct, but tag gap) |
- Lingua principale
- Go
- Stelle
- 1.5k
- Fork
- 390
- Merge medio
- 3g 58m
- PR unite (30g)
- 25
Preparare l'ambiente
- Include un Dockerfile o un file Docker Compose
- Ha un modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di 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)Forse già presa @sbackend123 l’ha presa 19 giorni fa. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 85/100
ethersphere/bee#5650 · 1 assegnatario ·
I maintainer di solito rispondono entro 2 giorni
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 35/100
ethersphere/bee#5678 ·
I maintainer di solito rispondono entro 2 giorni
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 48/100
ethersphere/bee#5666 ·
I maintainer di solito rispondono entro 2 giorni
-
Add a transaction inbox for outbound chain transactionsForse già presa @sbackend123 l’ha presa 13 giorni fa. Apertaseen
Difficoltà 5/5 Più di una settimana Idoneità per principianti 35/100
ethersphere/bee#5660 · 1 assegnatario ·
I maintainer di solito rispondono entro 2 giorni
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 45/100
ethersphere/bee#5659 · 6 commenti ·
I maintainer di solito rispondono entro 2 giorni
Tutte le issue di ethersphere/bee
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 65/100
kubernetes-sigs/kubebuilder#6131 ·
I maintainer di solito rispondono entro 2 giorni
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 65/100
aquasecurity/libbpfgo#560 ·
-
[BUG]Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 65/100
kagent-dev/kagent#3385 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
hashicorp/nomad-autoscaler#1364 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
theagentrouter/agent-router#2926 ·
I maintainer di solito rispondono entro 1 giorno