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

Misc fixes #560

Open
wants to merge 22 commits into
base: main
Choose a base branch
from
Open

Misc fixes #560

wants to merge 22 commits into from

Conversation

mpldr
Copy link

@mpldr mpldr commented Feb 26, 2024

Just some minor things I've noticed while perusing the codebase. This includes:

  • redundant function (util.ArrayContains)
  • string concatenation instead of format strings
  • unusual error handler signatures
  • unwarranted panic
  • weird error checks (strings.HasSuffix)
  • unnecessary nesting
  • bad package names (thumbnailing/{i,m,u}, **/_*)
  • unnecessary wrapper-functions/reimplementations (panic for failing regex compilation instead of regexp.MustCompile)
  • concurrency bugs
  • no use of the time.Time type to represent times

Since Go 1.21, there is a slices package in the standard library, that
implements the same functionality more comprehensively.

Replace the uses of ArrayContains with slices.Contains.
@mpldr mpldr force-pushed the misc-fixes branch 2 times, most recently from 576cf4b to 4044eb6 Compare February 27, 2024 19:52
@mpldr
Copy link
Author

mpldr commented Mar 2, 2024

okay, now for the scariest part…

@mpldr mpldr force-pushed the misc-fixes branch 3 times, most recently from d45c407 to 07ca3f2 Compare March 3, 2024 13:46
@mpldr mpldr marked this pull request as ready for review March 3, 2024 14:33
@mpldr mpldr changed the title WIP: Misc fixes Misc fixes Mar 3, 2024
@mpldr
Copy link
Author

mpldr commented Mar 3, 2024

A number of these can probably be added to the .git-blame-ignore-revs file

@turt2live turt2live self-requested a review March 4, 2024 18:52
Copy link
Member

@turt2live turt2live left a comment

Choose a reason for hiding this comment

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

Thanks for taking the time to submit these changes! A lot of them are agreeable and certainly improve the code quality, though several don't appear to consider why a particular decision was made.

I've left comments by going through the commits individually. For comments which affect the whole commit, I've arbitrarily left the comment on the first file so there's some visible threading in the github UI. I suggest reviewing this review by going through the commits individually.

It also appears as though some commits include unrelated changes, making it hard to accept this commit by commit. I would suggest making the changes recommended in this review and opening a dedicated PR for each task instead, encouraging commits to be distinct and limited in scope. This will also help with the eventual merge strategy, as MMR's policy is to squash merge rather than cherry pick or create a merge commit.

If you have any questions about the feedback here, please feel free to ask either here or in the support room.


// var NumericIdRegex = regexp.MustCompile("[0-9]+")
Copy link
Member

Choose a reason for hiding this comment

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

looks like this got moved down incorrectly

@@ -48,8 +52,8 @@ func GuestAuthFailed() *ErrorResponse {
return &ErrorResponse{common.ErrCodeNoGuests, "Guests cannot use this endpoint", common.ErrCodeNoGuests}
}

func BadRequest(message string) *ErrorResponse {
return &ErrorResponse{common.ErrCodeUnknown, message, common.ErrCodeBadRequest}
func BadRequest(err error) *ErrorResponse {
Copy link
Member

Choose a reason for hiding this comment

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

These functions deliberately do not take error objects to avoid accidentally leaking internal details to callers - please revert this change.

Copy link
Member

Choose a reason for hiding this comment

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

there's an exception to this rule later on in the federation test/info endpoints, as those endpoints are primarily used for debugging or by admins rather than random consumers.

@@ -70,59 +70,59 @@ func openDatabase(connectionString string, maxConns int, maxIdleConns int) error
var err error

if d.conn, err = sql.Open("postgres", connectionString); err != nil {
return errors.New("error connecting to db: " + err.Error())
return fmt.Errorf("error connecting to db: %w", err)
Copy link
Member

Choose a reason for hiding this comment

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

we should probably be using errors.Join() in these cases to avoid losing context on the stack.

Copy link
Author

Choose a reason for hiding this comment

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

%w is a special formatting instruction for fmt.Errorf() that wraps the error.

Copy link
Member

Choose a reason for hiding this comment

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

hmm, that feels a bit magic. errors.Join is more clear.

Comment on lines -18 to +22
var apiUrlCacheInstance *cache.Cache
var apiUrlSingletonLock = &sync.Once{}
var (
apiUrlCacheInstance *cache.Cache
apiUrlSingletonLock = &sync.Once{}
)
Copy link
Member

Choose a reason for hiding this comment

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

please undo this change

mediaChan <- media
}()
mediaChan <- media
close(mediaChan)
Copy link
Member

Choose a reason for hiding this comment

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

it's a bit uncomfortable to me to have the close in the goroutine when the channel is created externally - please restore the defer close(mediaChan) to avoid potential resource leaks.

Copy link
Author

Choose a reason for hiding this comment

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

No, this is a bug. Recovering from a panic does not remedy unclear channel ownership. The go routine for writing is no longer necessary since this is a buffered channel now. And the channel can just be closed afterwards. A simple look at the possible code paths confirms that there is no way the channel could remain unclosed.

Copy link
Member

Choose a reason for hiding this comment

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

The panic recovery is indeed a bug, though the defer close(mediaChan) needs to be moved up near the channel creation please. The remainder of the change is fine, I think.

Copy link
Author

Choose a reason for hiding this comment

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

No. This is a concurrency bug. The channel closing can be deferred in the writing function, but never outside of it. Otherwise, you end with a potential write on a closed channel. And since uploading likely takes a few milliseconds more than thumbnailing (at least on reasonably fast hardware), this will happen more often than not. So the best I could do is:

go func(){
    defer close(mediachan)
    // upload and stuff

Copy link
Member

Choose a reason for hiding this comment

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

We should be blocking on a read from the channel before the defer would fire - if we're not, then the concurrency is broken for sure. I'm not really comfortable using a different close style in a single section of the code, and would rather go out of the way to make defer close() immediately after creation work reliably.

Copy link
Member

Choose a reason for hiding this comment

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

please revert 6fc49c2 - the package naming is deliberate

Copy link
Member

Choose a reason for hiding this comment

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

please revert dc277e9 - the package naming is deliberate

Copy link
Member

Choose a reason for hiding this comment

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

please revert 1f3380e - the package naming is deliberate

Copy link
Member

Choose a reason for hiding this comment

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

please revert a31465b - the package naming is deliberate

Copy link
Member

Choose a reason for hiding this comment

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

please revert 0c957d8 - the package naming is deliberate

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.

2 participants