Skip to content
This repository has been archived by the owner on Aug 2, 2021. It is now read-only.

api, cmd, prod, pss, swarm: get publisher and query feed for chunk repair request #2175

Merged
merged 49 commits into from
May 12, 2020

Conversation

mortelli
Copy link
Contributor

@mortelli mortelli commented May 6, 2020

This PR is a WIP for the following task:

implement inheriting publisher info via the context.WithValue, construct and lookup the latest update of the pinners feed.

from issue #2161.

Implementation overview

  • NewRecoveryHook constructor func now also receives a feeds handler as a param, so the actual recovery hook can use it for feeds.
    • the handler passed to this constructor is the one created in the NewSwarm function.
  • prod.getPinners func now extracts a publisher string from the ctx param, gets the content from a feed using the address derived from the publisher, and unmarshals the content feed as targets to construct the trojan chunk.
  • adds a publisher flag for swarm up to register the publisher in the file manifest
  • adds a request header for upload with the publisher of the content

Tasks

  • add tests if possible
  • resolve TODOs or create new issues for them

@mortelli mortelli added in progress global pinning experimental implementation of global pinning labels May 6, 2020
@mortelli mortelli mentioned this pull request May 6, 2020
6 tasks
@@ -99,7 +99,7 @@ type NetStore struct {
requestGroup singleflight.Group
RemoteGet RemoteGetFunc
logger log.Logger
recoveryCallback func(ctx context.Context, chunkAddress chunk.Address) error // this is the function callback when a chunk failed to be retrieved
recoveryCallback func(ctx context.Context, chunkAddress chunk.Address, publisher string) error // this is the callback to be executed when a chunk fails to be retrieved
Copy link
Contributor Author

@mortelli mortelli May 6, 2020

Choose a reason for hiding this comment

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

publisher may not be a param here, but rather extracted from ctx

Copy link
Member

Choose a reason for hiding this comment

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

it makes sense to extract from context within the recovery function

Copy link
Contributor Author

Choose a reason for hiding this comment

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

removed this param, expecting code to be pushed to extract this data from ctx

@@ -167,7 +167,7 @@ func (n *NetStore) Close() error {
}

// WithRecoveryCallback allows injecting a callback func on the NetStore struct
func (n *NetStore) WithRecoveryCallback(f func(ctx context.Context, chunkAddress chunk.Address) error) *NetStore {
func (n *NetStore) WithRecoveryCallback(f func(ctx context.Context, chunkAddress chunk.Address, publisher string) error) *NetStore {
Copy link
Contributor Author

@mortelli mortelli May 6, 2020

Choose a reason for hiding this comment

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

Copy link
Contributor Author

Choose a reason for hiding this comment

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

resolution here

@@ -45,6 +45,12 @@ const MaxPayloadSize = 4030

var hashFunc = storage.MakeHashFunc(storage.BMTHash)

// RecoveryTopicText is the string used to construct the RecoveryTopic var
const RecoveryTopicText = "RECOVERY"
Copy link
Contributor Author

Choose a reason for hiding this comment

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

we need a separate string here as a const in order to build a feed.Topic var in the getPinners function (which is not of the trojan.Topic type)

Copy link
Member

Choose a reason for hiding this comment

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

this should not be here. trojan pkg not supposed to know about recovery

Copy link
Contributor Author

Choose a reason for hiding this comment

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

thanks, moved this to prod

prod/prod.go Show resolved Hide resolved
@@ -31,6 +31,13 @@ import (
"github.com/ethersphere/swarm/storage/feed/lookup"
)

// GenericHandler is an interface which specifies funcs any feeds handler should use
type GenericHandler interface {
Lookup(ctx context.Context, query *Query) (*cacheEntry, error)
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 is the signature as originally defined in the feeds package.

it seems strange to me that the cacheEntry type is not exported, since it is returned in the Lookup function, which is.

Copy link
Member

Choose a reason for hiding this comment

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

good point

prod/prod.go Outdated
Comment on lines 70 to 79
// get feed user from publisher
publisherBytes, err := hex.DecodeString(publisher)
if err != nil {
return nil, ErrPublisher
}
pubKey, err := crypto.DecompressPubkey(publisherBytes)
if err != nil {
return nil, ErrPubKey
}
addr := crypto.PubkeyToAddress(*pubKey)
Copy link
Contributor Author

@mortelli mortelli May 6, 2020

Choose a reason for hiding this comment

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

not entirely sure these are the steps to go from an (assumed) byte string as the publisher, to the actual User address for the feed.

as clarification: this code was adapted from api/act.go:245

Copy link
Member

Choose a reason for hiding this comment

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

looks good but this should defo be done only once instead of publisher, the derived ether address should be put in the context value

Copy link
Contributor Author

Choose a reason for hiding this comment

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

agreed, registered in #2181

prod/prod.go Outdated
// TODO: monitor return should
if _, err := send(ctx, targets, topic, payload); err != nil {
// TODO: returned monitor should be made use of
if _, err := send(ctx, targets, trojan.RecoveryTopic, payload); err != nil {
Copy link
Member

Choose a reason for hiding this comment

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

yes, we need the monitor here, I would block this until either parent context is done or monitor shows synced request

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 should be done in #2171

@mortelli
Copy link
Contributor Author

mortelli commented May 8, 2020

how about extracting the non-controversial parts in one or two PRs which we just merge?

* Targets  type in trojan package

* feed testutils and handler interface

then rebase this PR and we figure out contexts and how publisher gets in there etc

added PRs #2178 and #2179 for this.

thank you for the very appropriate suggestion

@santicomp2014 santicomp2014 marked this pull request as ready for review May 11, 2020 21:45
prod/prod.go Show resolved Hide resolved
prod/prod.go Show resolved Hide resolved
…ing-feeds

# Conflicts:
#	prod/prod.go
#	pss/pss_test.go
@mortelli
Copy link
Contributor Author

mortelli commented May 12, 2020

new related issue: #2180

Copy link
Contributor Author

@mortelli mortelli left a comment

Choose a reason for hiding this comment

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

quick overview of the stuff @zelig has not commented on

api/api.go Outdated Show resolved Hide resolved
api/api.go Outdated Show resolved Hide resolved
cmd/swarm/flags.go Show resolved Hide resolved
api/http/server.go Outdated Show resolved Hide resolved
prod/prod_test.go Outdated Show resolved Hide resolved
prod/prod_test.go Outdated Show resolved Hide resolved
@mortelli
Copy link
Contributor Author

new related issue: #2181

Copy link
Contributor Author

@mortelli mortelli left a comment

Choose a reason for hiding this comment

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

linter passes, so do tests, and all outstanding issues are documented.

GEFM, but i can't actually approve because i am the author of the PR 😂

prod/prod.go Show resolved Hide resolved
prod/prod.go Show resolved Hide resolved
Copy link
Contributor

@santicomp2014 santicomp2014 left a comment

Choose a reason for hiding this comment

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

@zelig zelig changed the title prod, chunk, pss, trojan, feed, storage, swarm: get publisher and query feed for chunk repair request api, cmd, prod, pss, swarm: get publisher and query feed for chunk repair request May 12, 2020
Copy link
Member

@zelig zelig left a comment

Choose a reason for hiding this comment

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

looks perfect

const RecoveryTopicText = "RECOVERY"

// RecoveryTopic is the topic used for repairing globally pinned chunks
var RecoveryTopic = trojan.NewTopic("RECOVERY")
Copy link
Member

Choose a reason for hiding this comment

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

here use RecoveryTopicText

Copy link
Contributor Author

Choose a reason for hiding this comment

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

whoops, this was left behind when i split the code into 2 more PRs.

fixed in the main branch, thanks

Topic: topic,
User: addr,
}
query := feed.NewQueryLatest(&fd, lookup.NoClue)
Copy link
Member

Choose a reason for hiding this comment

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

is this always lookup.NoClue? does it not store latest. state to be. used as hint?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

as of now, we do not have any idea when the last update to the feed happened, so this is why NoClue is used.

but i have added a note to #2181, we can further optimize it this way i think.

thanks

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
global pinning experimental implementation of global pinning ready for review
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants