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

Staticcheck cleanup #4751

Conversation

vytautas-karpavicius
Copy link
Contributor

@vytautas-karpavicius vytautas-karpavicius commented Feb 24, 2022

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/checks

Those 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

…t.TODO if you are unsure about which Context to use (SA1012)
@coveralls
Copy link

coveralls commented Feb 24, 2022

Pull Request Test Coverage Report for Build 1f83e6c5-190c-4e80-aa95-78a09dcf5978

  • 91 of 402 (22.64%) changed or added relevant lines in 70 files are covered.
  • 30 unchanged lines in 10 files lost coverage.
  • Overall coverage increased (+0.1%) to 56.98%

Changes Missing Coverage Covered Lines Changed/Added Lines %
common/elasticsearch/client_v6.go 0 1 0.0%
common/elasticsearch/client_v7.go 0 1 0.0%
common/persistence/executionManager.go 5 6 83.33%
common/persistence/nosql/nosqlQueueStore.go 0 1 0.0%
common/persistence/nosql/nosqlplugin/cassandra/tasks.go 0 1 0.0%
common/persistence/sql/common.go 0 1 0.0%
common/persistence/sql/sqlDomainStore.go 0 1 0.0%
common/persistence/sql/sqlExecutionStore.go 1 2 50.0%
common/persistence/sql/sqlQueueStore.go 0 1 0.0%
common/persistence/sql/sqldriver/connections.go 0 1 0.0%
Files with Coverage Reduction New Missed Lines %
cmd/server/cadence/cadence.go 1 7.64%
common/dynamicconfig/configstore/config_store_client.go 1 79.43%
common/persistence/persistence-tests/persistenceTestBase.go 1 8.88%
common/task/weightedRoundRobinTaskScheduler.go 1 89.64%
common/task/fifoTaskScheduler.go 2 85.57%
service/history/queue/timer_queue_processor.go 2 58.37%
service/matching/taskListManager.go 2 74.19%
tools/cli/adminElasticSearchCommands.go 2 0%
common/persistence/nosql/nosqlExecutionStore.go 5 62.65%
common/persistence/nosql/nosqlplugin/cassandra/workflow.go 13 53.98%
Totals Coverage Status
Change from base Build 860d5573-8102-4be3-9fd2-0a5813436b29: 0.1%
Covered Lines: 83200
Relevant Lines: 146015

💛 - Coveralls

@vytautas-karpavicius vytautas-karpavicius requested a review from a team February 24, 2022 14:22
@vytautas-karpavicius vytautas-karpavicius marked this pull request as ready for review February 24, 2022 14:22
Comment on lines -236 to -250
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
}

Copy link
Member

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

Copy link
Contributor Author

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
Copy link
Member

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")
Copy link
Member

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?

Copy link
Contributor Author

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{
Copy link
Member

Choose a reason for hiding this comment

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

ah. deprecated. 👍

Comment on lines -91 to -95
func print(v interface{}) {
fmt.Println("==============")
fmt.Println(v)
fmt.Println("==============")
}
Copy link
Member

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

Copy link
Contributor Author

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()
Copy link
Member

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.

Copy link
Contributor Author

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
Copy link
Member

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.)

Copy link
Contributor Author

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.

Comment on lines -1268 to -1270
if err := assertCurrentExecution(ctx, tx, shardID, domainID, workflowID, assertFn); err != nil {
return err
}
Copy link
Member

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
Copy link
Member

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)

Copy link
Contributor Author

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.

Comment on lines -359 to -364
func (g *EventGenerator) shouldBumpVersion() bool {
// 1//1000 to bump the version
//return g.dice.Intn(1000) == 500
return false
}

Copy link
Member

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: 👍)

binary.Write(buf, binary.LittleEndian, i)
binary.Write(buf, binary.LittleEndian, int32(i))
Copy link
Member

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

Copy link
Contributor Author

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{
Copy link
Member

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.

Comment on lines -21 to -22
//go:build !race
// +build !race
Copy link
Member

Choose a reason for hiding this comment

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

Copy link
Member

@Groxx Groxx Feb 24, 2022

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.

Copy link
Contributor Author

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
Copy link
Member

@Groxx Groxx Feb 25, 2022

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...

Copy link
Contributor Author

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
Copy link
Member

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}
Copy link
Member

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

Copy link
Contributor Author

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.

Comment on lines 715 to 718
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)
}
Copy link
Member

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?

Copy link
Contributor Author

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?

@Groxx
Copy link
Member

Groxx commented Feb 25, 2022

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 :)

@vytautas-karpavicius vytautas-karpavicius merged commit 7084679 into cadence-workflow:master Feb 28, 2022
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