Skip to content
This repository has been archived by the owner on Mar 28, 2023. It is now read-only.

FEATURE: Add endpoint to resolve peer IDs into IPNS entries. #1546

Merged
merged 2 commits into from
May 17, 2019

Conversation

drwasho
Copy link
Member

@drwasho drwasho commented Apr 16, 2019

No description provided.

@drwasho drwasho requested review from placer14 and cpacia April 16, 2019 01:10
@coveralls
Copy link

coveralls commented Apr 16, 2019

Coverage Status

Coverage decreased (-0.03%) to 35.607% when pulling 65831be on TS_resolve_ipns into 1000f97 on master.

Copy link
Member

@placer14 placer14 left a comment

Choose a reason for hiding this comment

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

Minor change request. Ensure the API docs are updated in Postman to include this new endpoint. GTM otherwise.

api/endpoints.go Outdated
@@ -195,6 +195,8 @@ func get(i *jsonAPIHandler, path string, w http.ResponseWriter, r *http.Request)
i.GETWalletStatus(w, r)
case strings.HasPrefix(path, "/ob/ipns"):
i.GETIPNS(w, r)
case strings.HasPrefix(path, "/ob/resolveipns"):
i.ResolveIPNS(w, r)
Copy link
Member

Choose a reason for hiding this comment

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

Core function ResolveIPNS does not follow pattern of HTTPVERBFunctionName. Nitpick: These two function calls are a little ambiguous to a newcomer. Any way to clarify?

Copy link
Member

Choose a reason for hiding this comment

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

You're right, I totally overlooked the http verb prefix thing. I'll fix that.

Copy link
Member

Choose a reason for hiding this comment

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

I'm not sure how to clarify without renaming /ob/ipns, which would not be ideal.

One option would be making it a flag on /ob/ipns, e.g. /ob/ipns?resolve=true

Copy link
Member

Choose a reason for hiding this comment

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

I can't think of any suggestions to offer either. We can punt if we can't think of anything better. I think the GET param overloads the endpoint with two different behaviors. And really, I would want to change the ipns endpoint to be more specific, but that has repercussions which are annoying. We can leave it as-is for now.

return
}

ctx, cancel := context.WithTimeout(context.Background(), time.Second*180)
Copy link
Member

Choose a reason for hiding this comment

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

The timeout for this call is 2 minutes. Is this intended? /cc @drwasho

Copy link
Member

@tyler-smith tyler-smith Apr 17, 2019

Choose a reason for hiding this comment

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

Yeah I need it to be at least 2 minutes but we could make it configurable if somebody only wanted entries that resolve quickly but clients should use a timeout on their side anyways.

Copy link
Member

Choose a reason for hiding this comment

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

This is no problem for me, I just want to make sure this was intended.

@placer14 placer14 self-requested a review April 17, 2019 13:36
Copy link
Member

@placer14 placer14 left a comment

Choose a reason for hiding this comment

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

(Pressed Approve instead of Request Changes.)

@cpacia
Copy link
Member

cpacia commented May 14, 2019

Looks good.

@placer14 placer14 merged commit 4177b79 into master May 17, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants