-
Notifications
You must be signed in to change notification settings - Fork 816
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
Staticcheck cleanup #4751
Staticcheck cleanup #4751
Conversation
…r.TreeID] (S1002)
…estors...) (S1011)
…t.TODO if you are unsure about which Context to use (SA1012)
… type to avoid collisions (SA1029)
…/cadence into staticcheck-cleanup
func (p *queryParser) convertCloseTime(timestamp int64, op string, parsedQuery *parsedQuery) error { | ||
switch op { | ||
case "=": | ||
if err := p.convertCloseTime(timestamp, ">=", parsedQuery); err != nil { | ||
return err | ||
} | ||
if err := p.convertCloseTime(timestamp, "<=", parsedQuery); err != nil { | ||
return err | ||
} | ||
default: | ||
return fmt.Errorf("operator %s is not supported for close time", op) | ||
} | ||
return nil | ||
} | ||
|
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.
unused or something? afaik this is correct for BigQuery-style datastores
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.
Yeah this is unused.
@@ -68,7 +68,6 @@ type ( | |||
s3cli s3iface.S3API | |||
// only set in test code | |||
historyIterator archiver.HistoryIterator | |||
config *config.S3Archiver |
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.
apparently this config is now contained in the s3cli
, so 👍
errEmptyDomainName = errors.New("Domain name is empty") | ||
errEmptyDomainName = errors.New("DomainName is empty") |
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.
staticcheck complained about this? or did it just complain about uppercase -> now it matches the param name, and staticcheck is happy because it looks like a ProperNoun or something?
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.
staticcheck
complained about upper case. Since other errors here include exact param names, I changed this for consistency as well.
Out of curiosity checked their source code: https://github.com/dominikh/go-tools/blob/f41ebe766a412094c088d7d32598c19442db66c1/stylecheck/lint.go#L418
Seems like if it detects more upper letters in the first word - it is ok:
// Word is probably an initialism or
// multi-word function name
statter, err := statsd.NewBufferedClient(config.HostPort, config.Prefix, config.FlushInterval, config.FlushBytes) | ||
statter, err := statsd.NewClientWithConfig(&statsd.ClientConfig{ |
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.
ah. deprecated. 👍
func print(v interface{}) { | ||
fmt.Println("==============") | ||
fmt.Println(v) | ||
fmt.Println("==============") | ||
} |
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.
honestly I wonder if we can find a linter to just ban fmt.Print*
across the board. it's basically always better-served by some injected thing, like a logger
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.
Quickly searched for such usages. Majority of the comes in CLI or in tests. Those are probably valid uses.
@@ -49,8 +49,7 @@ func TestDefaultLogger(t *testing.T) { | |||
outC <- buf.String() | |||
}() | |||
|
|||
var zapLogger *zap.Logger | |||
zapLogger = zap.NewExample() | |||
zapLogger := zap.NewExample() |
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.
would it cause any problems to change these to zaptest.New(t)
instead? then logs will be scoped to the test.
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.
Tried changing this - tests fail.
I think zaptest.New(t)
is good for places when you just want to pass some logger when testing things and do no pollute output for passed tests. There are some places that could be updated to use it.
Here however, we testing the logger implementation itself.
RetentionSeconds time.Duration | ||
RetentionPeriod time.Duration |
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.
minor honestly, but do we have any broad pattern for this kind of thing for "period" vs "interval"? since it's a bit odd to do it two ways in the same file.
(not that I think either is wrong, they kinda are different meanings. just wondering out loud if consistency would be better.)
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.
Yeah I thought about it.
But if we decide to do it, we should change it everywhere. Period
mostly goes with workflow retention, Interval
is very common for retry policy fields. We also have lots of Timeout
fields as well.
This would be big change. I'm not against it, but IMHO this is very low priority item.
if err := assertCurrentExecution(ctx, tx, shardID, domainID, workflowID, assertFn); err != nil { | ||
return err | ||
} |
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.
since this does a DB lock: is this something we should be calling, or is it being handled somewhere else?
return true | ||
} | ||
return false | ||
return err == sql.ErrNoRows |
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.
since we're working on wrapped errors: are you on a recent master? I'm not sure what the sequencing of these changes is. since this'd be a fairly obvious errors.Is(err, sql.ErrNoRows)
transformation.
(but probably not worth doing in this PR, keep this one full of obviously-noops)
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.
This is on recent master.
Yeah, lets leave it a separate PR, that addresses such cases.
func (g *EventGenerator) shouldBumpVersion() bool { | ||
// 1//1000 to bump the version | ||
//return g.dice.Intn(1000) == 500 | ||
return false | ||
} | ||
|
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.
huh. wonder if this would be useful to enable in tests. (but if unused: 👍)
host/integration_test.go
Outdated
binary.Write(buf, binary.LittleEndian, i) | ||
binary.Write(buf, binary.LittleEndian, int32(i)) |
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.
any reason for int32 vs int64? I think this was behaving as int64, as int is architecture-dependent and basically nobody uses 32-bit for servers
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.
Good point, apparently I'm living in the past :)
Updated.
events = s.getHistory(s.domainName, &types.WorkflowExecution{ | ||
s.getHistory(s.domainName, &types.WorkflowExecution{ |
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.
With errcheck (or similar), I guess this is probably preferable over _ = s.getHistory(...)
, isn't it... since that could be ignoring an error, but s.getHistory(...)
cannot. Interesting.
//go:build !race | ||
// +build !race |
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.
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.
that aside: could that be marking this as incorrectly-unused? and/or is there anything worth saving in here? we should just fix the races.
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.
This entire test suite is unused and disabled for 10 months already.
AFAICT we have another similar suite in host/ndc
. Might be worth double checking with the team.
@@ -848,6 +848,7 @@ func (s *engine2Suite) createExecutionStartedState(we types.WorkflowExecution, t | |||
} | |||
|
|||
//nolint:unused | |||
//lint:ignore U1000 for printing within tests |
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.
huh. is it complaining because of the name? maybe better to just change the name...
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.
This is currently not used anywhere, so we could remove it entirely.
Since I saw previous nolint
I assumed this may be sometimes used for debugging in tests, so added additional declaration for staticcheck.
Not sure whether it is worth keeping such helpers though...
require.Error(t, errRemoteSyncMatchFailed) // should not persist the task | ||
require.Error(t, err) // should not persist the task |
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.
lol. well that's a more useful test now
@@ -43,6 +43,8 @@ import ( | |||
|
|||
const testWorkflowName = "default-test-workflow-type-name" | |||
|
|||
var validBranchToken = []byte{89, 11, 0, 10, 0, 0, 0, 12, 116, 101, 115, 116, 45, 116, 114, 101, 101, 45, 105, 100, 11, 0, 20, 0, 0, 0, 14, 116, 101, 115, 116, 45, 98, 114, 97, 110, 99, 104, 45, 105, 100, 0} |
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.
👍👍 for more valid values, though is there a more human-friendly way to build this? as it apparently includes "test-tree-id" and "test-branch-id" strings
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.
Copied it from some other place, as the test actually started failing after checking for errors :)
This is thrift serialized structure underneath. I guess we could have helpers in our test to generate those.
match, err := regexp.MatchString(defaultDateTimeRangeShortRE, timeRange) | ||
if !match { // fallback on to check if it's of longer notation | ||
match, err = regexp.MatchString(defaultDateTimeRangeLongRE, timeRange) | ||
_, err = regexp.MatchString(defaultDateTimeRangeLongRE, timeRange) | ||
} |
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.
not necessarily relevant as this doesn't change behavior, but: what if the second doesn't match? looks like regexp.MatchString
will only error if the regex fails to compile.
more generally, it seems pretty obvious that we should only be compiling these once, rather than on every call :\ think that's worth doing here, or later?
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.
Good observation. Few problems here:
- regexes are not compiled as you mentioned (although not very impactful as those are used only on CLI commands)
- these matches are not used anywhere. Error simply check whether they compile.
- Match groups in those regexes are not utilized, we parse things manually below
I think I will address this in a separate PR. Also checked that there exists a library for such functionality: https://github.com/karrick/tparse
What is opinion on taking this dependency? Or just simply fixing is enough?
notes are worth checking, but LGTM either way, and they're nearly all just observations / questions. Let me know if you'd like me to check any changes you do end up making :) |
Co-authored-by: Steven L <imgroxx@gmail.com>
What changed?
Cleaned up lots of code according to
staticcheck
suggestions. Each commits deals with one suggestion at a time. I have included suggestion code which can be looked up here: https://staticcheck.io/docs/checksThose changes are mostly mechanical. There are more warning the tool reports, that may affect functionality. I will try to address those separately.
Why?
To clean up our codebase and make more consistent with best go practices.
How did you test it?
Potential risks
Release notes
Documentation Changes