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

feat: findProvidersAsync #938

Merged
merged 3 commits into from
Sep 26, 2023
Merged

Conversation

dennis-tra
Copy link
Contributor

fixes: #915

@dennis-tra dennis-tra force-pushed the v2-issue-915-find-providers-async branch from 63122cb to f1dacf1 Compare September 26, 2023 14:54
@dennis-tra dennis-tra marked this pull request as ready for review September 26, 2023 14:59
@dennis-tra dennis-tra requested a review from iand as a code owner September 26, 2023 14:59
Copy link

@iand iand left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good. Some general questions and minor suggestions.

@@ -78,6 +78,33 @@ func TestConfig_Validate(t *testing.T) {
assert.Error(t, cfg.Validate())
})

t.Run("backends for ipfs protocol (public key missing)", func(t *testing.T) {
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is possible to support only one or two backends? Suppose we don't want to support IPNS records - do we still need to declare it in the config?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, that's possible but only if the configured protocol is not /ipfs/kad/1.0.0. This was recommended by Adin (can't find the link to the conversation).

I'm trying to enforce that if someone configures the DHT with the /ipfs/kad/1.0.0 protocol, all the required backends are there. If someone wants to, they can still misconfigure it - but this makes it harder.


// verify if this DHT supports provider records by checking
// if a "providers" backend is registered.
b, found := d.backends[namespaceProviders]
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we search for providers without having a backend to store them? How would that work?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, when we search for providers, we won't store them anywhere. This is just checking if we support providers. Other users could configure custom backends for other types of records but the DHT will still support the routing.Routing interface. In that case we won't have the right backend configured here.

panic("implement me")
// first fetch the record locally
stored, err := b.Fetch(ctx, string(c.Hash()))
if err != nil {
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this check for not found errors?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This would be necessary if this was the datastore Get method. This is the backend Fetch method. The backend returns a *providerSet. If there are no providers, the set will be empty. IIRC internally the backend will query the datastore (not Get). This means even the datastore won't return a NotFound error.

case out <- provider:
}

if count != 0 && len(providers) == count {
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

count != 0 isn't strictly necessary since len(providers) can never be zero here

@dennis-tra dennis-tra merged commit dd5e537 into v2-develop Sep 26, 2023
@dennis-tra dennis-tra deleted the v2-issue-915-find-providers-async branch September 26, 2023 15:48
@Jorropo Jorropo added the v2 All issues related to the v2 rewrite label Oct 20, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
v2 All issues related to the v2 rewrite
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants