You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Making this issue to track a potential race condition in bitswap. When adding a block to bitswap, the incoming block is passed through to the notifications lib and published to anyone waiting for that block. In the case that someone has called GetBlock on the block and then we add it locally, two different goroutines would have the same 'block'. This is only a problem in cases where we mutate the node on the adders side after the add call.
Doing a simple ipfs cat h(X) in one shell before h(X) exists, and then running ipfs add X does not even trigger the race detector.
The text was updated successfully, but these errors were encountered:
I think this is a non-issue and unrelated. This appears to be about returning the same block object to multiple clients which should be totally fine (they're immutable (well, we copy before mutating at least).
Making this issue to track a potential race condition in bitswap. When adding a block to bitswap, the incoming block is passed through to the notifications lib and published to anyone waiting for that block. In the case that someone has called
GetBlock
on the block and then we add it locally, two different goroutines would have the same 'block'. This is only a problem in cases where we mutate the node on the adders side after the add call.Doing a simple
ipfs cat h(X)
in one shell beforeh(X)
exists, and then runningipfs add X
does not even trigger the race detector.The text was updated successfully, but these errors were encountered: