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: HTTP config #2278

Merged
merged 9 commits into from
Feb 7, 2024
Merged

Conversation

nasdf
Copy link
Member

@nasdf nasdf commented Feb 1, 2024

Relevant issue(s)

Resolves #2277

Description

This PR is a refactor of the HTTP config and is part of the larger config refactor #2257

Tasks

  • I made sure the code is well commented, particularly hard-to-understand areas.
  • I made sure the repository-held documentation is changed accordingly.
  • I made sure the pull request title adheres to the conventional commit style (the subset used in the project can be found in tools/configs/chglog/config.yml).
  • I made sure to discuss its limitations such as threats to validity, vulnerability to mistake and misuse, robustness to invalidation of assumptions, resource requirements, ...

How has this been tested?

make test

Specify the platform(s) on which this was tested:

  • MacOS

@nasdf nasdf requested a review from a team February 1, 2024 19:53
Copy link

codecov bot commented Feb 1, 2024

Codecov Report

Attention: 17 lines in your changes are missing coverage. Please review.

Comparison is base (36315e4) 74.03% compared to head (3a6c4b4) 73.97%.

Additional details and impacted files

Impacted file tree graph

@@             Coverage Diff             @@
##           develop    #2278      +/-   ##
===========================================
- Coverage    74.03%   73.97%   -0.07%     
===========================================
  Files          256      256              
  Lines        25695    25587     -108     
===========================================
- Hits         19023    18926      -97     
+ Misses        5356     5346      -10     
+ Partials      1316     1315       -1     
Flag Coverage Δ
all-tests 73.97% <81.52%> (-0.07%) ⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files Coverage Δ
http/handler.go 76.19% <100.00%> (-1.75%) ⬇️
http/server.go 100.00% <100.00%> (+5.08%) ⬆️
http/middleware.go 75.68% <75.00%> (+5.94%) ⬆️
config/config.go 72.33% <33.33%> (-1.86%) ⬇️
cli/start.go 26.38% <0.00%> (+0.97%) ⬆️

... and 7 files with indirect coverage changes


Continue to review full report in Codecov by Sentry.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 36315e4...3a6c4b4. Read the comment docs.

@nasdf nasdf self-assigned this Feb 5, 2024
@nasdf nasdf added the area/config Related to configuration label Feb 5, 2024
Copy link
Contributor

@AndrewSisley AndrewSisley left a comment

Choose a reason for hiding this comment

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

praise: Code looks much simpler, thank you :)

Only a couple of comments from me, but please address them before merge :)

http/server.go Outdated
}
// ignore close errors as they cannot be handled
// from the caller of this method
defer listener.Close() //nolint:errcheck
Copy link
Contributor

Choose a reason for hiding this comment

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

question: Why can they not be handled but other errors appear to be so? And is that not up to any callers of this public function to decide? Should the choice to discard the error not be made by the caller?

Copy link
Member Author

Choose a reason for hiding this comment

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

I've removed this Close call as it is redundant. After taking a closer look the Serve and ServeTLS functions will close the listener.

http/server.go Outdated
return nil
// Server struct holds the Handler for the HTTP API.
type Server struct {
address atomic.Value
Copy link
Contributor

Choose a reason for hiding this comment

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

question: Why is this atomic? It only appears to be set once, in ListenAndServe, and that function cannot be called multiple times concurrently no?

todo: If it remains atomic, please document why.

Copy link
Member Author

Choose a reason for hiding this comment

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

I've added documentation to clarify the use of the atomic value.

Copy link
Contributor

@AndrewSisley AndrewSisley Feb 6, 2024

Choose a reason for hiding this comment

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

Ah, you want AssignedAddr to return empty if ListenAndServe is in progress? Would it not be better to lock, and block AssignedAddr from returning until the address has been assigned? (i.e. no atomic, but a RWLock opened on the first line of ListenAndServe)

Copy link
Member Author

@nasdf nasdf Feb 6, 2024

Choose a reason for hiding this comment

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

I agree that would be better, but I realized we don't use this method anywhere outside of server_test.go. I've removed the AssignedAddr function and address property from server.

As a side note: tests that need a random port assignment should use the httptest package instead.

Copy link
Collaborator

Choose a reason for hiding this comment

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

As a side note: tests that need a random port assignment should use the httptest package instead.

That's a really nice change. Thanks for removing the need to keep track of the randomly assigned port on the http server :)

@nasdf nasdf merged commit 216db8f into sourcenetwork:develop Feb 7, 2024
31 of 32 checks passed
shahzadlone pushed a commit to shahzadlone/defradb that referenced this pull request Feb 23, 2024
## Relevant issue(s)

Resolves sourcenetwork#2277 

## Description

This PR is a refactor of the HTTP config and is part of the larger
config refactor sourcenetwork#2257

## Tasks

- [x] I made sure the code is well commented, particularly
hard-to-understand areas.
- [x] I made sure the repository-held documentation is changed
accordingly.
- [x] I made sure the pull request title adheres to the conventional
commit style (the subset used in the project can be found in
[tools/configs/chglog/config.yml](tools/configs/chglog/config.yml)).
- [x] I made sure to discuss its limitations such as threats to
validity, vulnerability to mistake and misuse, robustness to
invalidation of assumptions, resource requirements, ...

## How has this been tested?

make test

Specify the platform(s) on which this was tested:
- MacOS
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/config Related to configuration
Projects
None yet
Development

Successfully merging this pull request may close these issues.

HTTP config refactor
3 participants