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

chore: make thorclient configurable #907

Closed
wants to merge 1 commit into from

Conversation

darrenvechain
Copy link
Member

Description

Make thorclient more configurable my specifying *http.Client

Checklist:

  • My code follows the style guidelines of this project
  • I have performed a self-review of my code
  • I have commented my code, particularly in hard-to-understand areas
  • I have made corresponding changes to the documentation
  • My changes generate no new warnings
  • I have added tests that prove my fix is effective or that my feature works
  • New and existing unit tests pass locally with my changes
  • New and existing E2E tests pass locally with my changes
  • Any dependent changes have been merged and published in downstream modules
  • I have not added any vulnerable dependencies to my code

@darrenvechain darrenvechain requested a review from a team as a code owner December 5, 2024 09:07
@codecov-commenter
Copy link

Codecov Report

Attention: Patch coverage is 66.66667% with 2 lines in your changes missing coverage. Please review.

Project coverage is 60.65%. Comparing base (cebfc39) to head (e024a9e).

Files with missing lines Patch % Lines
thorclient/thorclient.go 50.00% 2 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##           master     #907      +/-   ##
==========================================
+ Coverage   60.52%   60.65%   +0.12%     
==========================================
  Files         215      215              
  Lines       23111    23111              
==========================================
+ Hits        13987    14017      +30     
+ Misses       7976     7945      -31     
- Partials     1148     1149       +1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Copy link
Member

@otherview otherview left a comment

Choose a reason for hiding this comment

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

I think this is the right path forward, the http object is always instantiated without params in the New().

To avoid having client := New(ts.URL, &http.Client{}) everywhere, would it make sense to have client := New(ts.URL) (which has the default httpclient) and client := NewWithHTTP(ts.URL, &http.Client{}) ?

@darrenvechain
Copy link
Member Author

darrenvechain commented Dec 5, 2024

I think this is the right path forward, the http object is always instantiated without params in the New().

To avoid having client := New(ts.URL, &http.Client{}) everywhere, would it make sense to have client := New(ts.URL) (which has the default httpclient) and client := NewWithHTTP(ts.URL, &http.Client{}) ?

Ya I had considered this, but my reasoning was that as a client of the codebase you probably only have to init the client once and pass the struct around your app.

We have a lot of &http.Client{} because we use it a lot in our tests, and IMO its not that hard to initialise it.

I don't feel strongly either way

@otherview
Copy link
Member

I think this is the right path forward, the http object is always instantiated without params in the New().
To avoid having client := New(ts.URL, &http.Client{}) everywhere, would it make sense to have client := New(ts.URL) (which has the default httpclient) and client := NewWithHTTP(ts.URL, &http.Client{}) ?

Ya I had considered this, but my reasoning was that as a client of the codebase you probably only have to init the client once and pass the struct around your app.

We have a lot of &http.Client{} because we use it a lot in our tests, and IMO its not that hard to initialise it.

I don't feel strongly either way

The initial idea was to follow how ethclient instantiates a connection ( by under the wood, creating the connector ).
I think having an exposed http connector is helpful for setting up specialized http properties like traffic routing/doubling httclient reusage, like we do in draupnir. It's good to have that option but from what I can gather, that kind of usage seems to be the particular usage, the norm seems to be the default http client.

@darrenvechain darrenvechain deleted the darren/chore/thorclient-specify-http branch December 9, 2024 17:21
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