Bee is a Swarm client implemented in Go. It’s the basic building block for the Swarm network: a private; decentralized; and self-sustaining network for permissionless publishing and access to your (application) data.
This is not only asymmetrical, but it can cause disagreement in the reserve database if two or more payloads being uploaded under one single owner chunk with the same postage batch.
Expected behavior
Reserve key handling is identical with the one that pullsync protocol has and it handles multiple SOC payloads with the same postage ID
Actual behavior
downstream will reject the 2nd SOC because the previous delete call on wantChunks
Context
recent master; haven't tested but it may lead to shelling point mismatch.
Summary
Reserve storage is checked against chunk address, batch ID and fingerprint of batch serialization. https://github.com/ethersphere/bee/blob/master/pkg/pullsync/pullsync.go#L186
The main problem is that the pull syncing operates with different key composition than the reserve store has. https://github.com/ethersphere/bee/blob/master/pkg/pullsync/pullsync.go#L230
This is not only asymmetrical, but it can cause disagreement in the reserve database if two or more payloads being uploaded under one single owner chunk with the same postage batch.
Expected behavior
Reserve key handling is identical with the one that pullsync protocol has and it handles multiple SOC payloads with the same postage ID
Actual behavior
downstream will reject the 2nd SOC because the previous delete call on
wantChunksSteps to reproduce
Possible solution