Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
git.Command.Run*
, introduceRunWithContextString
andRunWithContextBytes
#19266Refactor
git.Command.Run*
, introduceRunWithContextString
andRunWithContextBytes
#19266Changes from 4 commits
956a4b5
25c5e87
7e17fee
9d15eda
8a7e50f
943167f
7fff081
817736e
868d55e
4f395dc
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems like there are some user-defined timeouts being passed to this function, I'm not sure that in the middle of normal operations a panic should occur from a process...
Reference:
gitea/services/mailer/mailer.go
Line 276 in a82fd98
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hm that would mean we either should fail on gitea init or put out a warn and ignore this setting
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Gusted
When passing timeout<=0 into AddContextTimeout:
From my experience, in a big and complex system, everything should be defined as a clear behavior, if there is something unexpected happening, the error should be reported in the first time. We should always expose mistakes, instead of hiding mistakes.
So I think this new mechanism is better and more stable, this refactoring is only done in 1.17 and we have enough time to catch more bugs in future.
And fortunately, the
SendmailTimeout
has a default value:SendmailTimeout: sec.Key("SENDMAIL_TIMEOUT").MustDuration(5 * time.Minute),
, so there will be no problem now. As an exmple, if user set SendmailTimeout=-1 in old code, the user only sees some non-sense errors likecontext cancelled
. Now, the user knows that the timeout is wrong. And when he reports the bug to gitea issues, the panic message is also very clear for maintainers.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Or we could ignore the timeout context if timeout <= 0 but not panic
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, ignoring non-sense values in low-level frameworks is wrong. Many Go functions also panic if there is an invalid input.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should prevent such issues from being reported. I'm not sure at which level the context cancelled are being reported to the admin, but otherwise it might be their "first time" that they observe that their configuration is incorrect. I think we should have a little note in the 1.17 announcement that a negative timeout can lead to panics and errors and that
0
should be used instead.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Many were written without being able to return errors, and given they don't want to break backwards compatibility, they instead panic.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why do we need to mention that? If users were using
-1
or0
, how can their system work correctly? And0
is also incorrect for a timeout, it should be handled by Gitea's setting module to set to a default timeout, this work can not be done automatically.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have no clue, but from what I've learned is that people can somehow survive with incorrect configurations without noticing. Anyhow, approving.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To be clear:
If a user were using
-1
or0
, and their system works correctly, after this PR, nothing changes. Because these values were processed to defaults correctly by Gitea already.If a user were using
-1
or0
and their system didn't work correctly, before this PR they knew nothing, after this PR they know that there is something wrong. That's a improvement.ps: I agree "people can somehow survive with incorrect configurations without noticing.", however, once they meet some errors and report "bugs", it makes maintainers frustrated ..... nobody can guess what's wrong on user side if mistakes are hidden. We really need a clear system 😊