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

refactor(providerindex): accept multiple legacy options #86

Draft
wants to merge 3 commits into
base: fix/claim-fallback-cid
Choose a base branch
from

Conversation

hannahhoward
Copy link
Member

Goals

Get a full roundtrip to work with freeway -- these are all the additional changes required

Implementation

  • update go-capabilities to include fixes from fix(assert): fix casing on other caveats schema types go-capabilities#6 (which had not been updated in a minute, so there are a few changes required)
  • modify the legacy claims finder to work with multiple claim mappers, and be sensitive to target claims. the reason for this is as follows -- I had assumed by fallback mapper could simply run on top of the base legacy mapper and run when the legacy mapper returns no claims. however, in practice, we end up in a situation where we are specifically looking for a Shard CID location claim, and the base legacy mapper returns a Shard CID EQUALS claim. So we need to have that filtered out and then run my fallback mapper anyway. This ends up making much more sense to do at the legacy claims finder level than in the fallback mapper.

For Discussion

Still need to add some new test cases for the legacy claims finders now that it uses multiple mappers & handles filtering

Copy link

codecov bot commented Jan 12, 2025

Copy link
Member

@alanshaw alanshaw left a comment

Choose a reason for hiding this comment

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

Incredible debugging!

Copy link
Member

@volmedo volmedo left a comment

Choose a reason for hiding this comment

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

that's an interesting corner case! Implementation looks good, I left some minor comments.

pkg/construct/construct.go Outdated Show resolved Hide resolved
}

// LegacyClaimsStore allows finding claims on a legacy store
type LegacyClaimsStore struct {
contentToClaims ContentToClaimsMapper
contentToClaims []ContentToClaimsMapper
Copy link
Member

Choose a reason for hiding this comment

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

np: I'd rename this to mappers or something like that, now that there may be several of them

return nil, nil
}

func (ls LegacyClaimsStore) findOne(ctx context.Context, contentHash multihash.Multihash, targetClaims []multicodec.Code, mapper ContentToClaimsMapper) ([]model.ProviderResult, error) {
Copy link
Member

Choose a reason for hiding this comment

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

why is this function called findOne? maybe it had a different goal before?

Copy link
Member Author

Choose a reason for hiding this comment

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

it's checking one mapper when the function above checks many

Copy link
Member

Choose a reason for hiding this comment

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

got it. The very first thing that came to my mind was "find one result". I guess I'm too used to datastore APIs :)

Comment on lines +71 to +79
for _, mapper := range ls.contentToClaims {
claims, err := ls.findOne(ctx, contentHash, targetClaims, mapper)
if err != nil {
return nil, err
}
if len(claims) > 0 {
return claims, nil
}
}
Copy link
Member

Choose a reason for hiding this comment

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

the results of this logic will depend on the order the mappers are provided in the slice. The results being returned will be the ones given by the first mapper returning any result.

Not saying it's wrong, but it may be worth stating it clearly somewhere (in the comment for NewLegacyClaimsStore, maybe?).

Copy link
Member Author

Choose a reason for hiding this comment

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

yes that's the goal, but it's absolutely worst stating

Copy link
Member

Choose a reason for hiding this comment

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

maybe add a test for correct filtering of claims according to targetClaims?

Copy link
Member Author

Choose a reason for hiding this comment

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

yea

pkg/service/providerindex/legacy.go Outdated Show resolved Hide resolved
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

Successfully merging this pull request may close these issues.

3 participants