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
Currently if you are falling behind re-provides the content will be announced based on randomish order:
case"all", "":
keyProvider=fx.Provide(provider.NewBlockstoreProvider) // order depends on iteration of the blockstorecase"roots":
keyProvider=fx.Provide(pinnedProviderStrategy(true)) // rootscase"pinned":
keyProvider=fx.Provide(pinnedProviderStrategy(false)) // dfs iteration of pins
all and pinned should start by providing roots, I think it is fine to have them provide roots twice given the graph is bottom heavy this is negligible cost.
This means if your node is running the classic dht client and it is falling behind, you at least will have the roots of what you pinned announced correctly.
We might also want to do that after ipfs pin add and ipfs add (they would skip the reprovider directly and hit the dht) if we don't already do this.
This should allow users to run a classic DHT client while having things mostly work in situations like #10192.
The text was updated successfully, but these errors were encountered:
Currently if you are falling behind re-provides the content will be announced based on randomish order:
all
andpinned
should start by providing roots, I think it is fine to have them provide roots twice given the graph is bottom heavy this is negligible cost.This means if your node is running the classic dht client and it is falling behind, you at least will have the roots of what you pinned announced correctly.
We might also want to do that after
ipfs pin add
andipfs add
(they would skip the reprovider directly and hit the dht) if we don't already do this.This should allow users to run a classic DHT client while having things mostly work in situations like #10192.
The text was updated successfully, but these errors were encountered: