Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

When enabled Reprovider should always start with roots strategy. #10193

Open
Jorropo opened this issue Nov 2, 2023 · 0 comments
Open

When enabled Reprovider should always start with roots strategy. #10193

Jorropo opened this issue Nov 2, 2023 · 0 comments

Comments

@Jorropo
Copy link
Contributor

Jorropo commented Nov 2, 2023

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 blockstore
	case "roots":
		keyProvider = fx.Provide(pinnedProviderStrategy(true)) // roots
	case "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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant