revive: panic: unable to type check
Describe the bug We’ve seen a transient panic in revive in our CI job (it did not occur when the job was retried).
revive -exclude vendor/... -formatter friendly -config .revive.toml ./...
panic: unable to type check [redacted file A]:[redacted file A]:3:8: could not import [redacted pkg B] (can't find import: [redacted pkg B])
goroutine 123 [running]:
github.com/mgechev/revive/rule.(*EmptyBlockRule).Apply(0x9e06d0, 0xc000f70b80, 0x0, 0x0, 0x0, 0x9e06d0, 0x0, 0x0)
/go/src/github.com/mgechev/revive/rule/empty-block.go:23 +0x20e
github.com/mgechev/revive/lint.(*File).lint(0xc000f70b80, 0xc0003b6800, 0x27, 0x40, 0x0, 0x3fd0000000000000, 0xc000030a40, 0x7, 0xc00007dfb0, 0x1, ...)
/go/src/github.com/mgechev/revive/lint/file.go:108 +0x3b6
github.com/mgechev/revive/lint.(*Package).lint.func1(0xc0003b6800, 0x27, 0x40, 0x0, 0x3fd0000000000000, 0xc000030a40, 0x7, 0xc00007dfb0, 0x1, 0x1, ...)
/go/src/github.com/mgechev/revive/lint/package.go:173 +0xb5
created by github.com/mgechev/revive/lint.(*Package).lint
/go/src/github.com/mgechev/revive/lint/package.go:172 +0x179
To Reproduce
I couldn’t reproduce the issue - it worked when I retried the job. Could it have been caused by some network issue when getting the package from our internal git repo?
Expected behavior Expected to see better error message describing why it couldn’t find the import.
Desktop (please complete the following information):
- Version of Go: 1.14.2
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Comments: 16 (3 by maintainers)
Commits related to this issue
- Add reproducer code for revive issue 416 https://github.com/mgechev/revive/issues/416 — committed to kiwicom/revive by martin-sucha 4 years ago
- Add reproducer code for revive issue 416 https://github.com/mgechev/revive/issues/416 — committed to kiwicom/revive by martin-sucha 4 years ago
I see you removed the type check, which will fix the issue with panic.
However, the type checking might still be failing in the other rules as well, the error is just suppressed, so it would be good to find the root cause of this.
I managed to reproduce the panic (on version of code before you removed it from the empty-block rule) with just revive repo and it seems to happen more often than on the private repo we encountered the issue on. To reproduce, just checkout https://github.com/kiwicom/revive/commits/ms/issue-416-repro branch, build revive with
make build
and then run./repro.sh
. Alternately there is a version that records the run with Mozilla RR (go build -gcflags "all=-N -l" && ./repro-rr.sh
) and a version that runs it in Docker (./repro-docker.sh
)Ultimately, I think we should find out whether the
can't find import
is caused by an issue in revive (e.g. not callingtypes.Config.Check
correctly in some cases) or whether this is Go issue (and report it there, possibly with even smaller reproducer).The first option seems more deterministic. Alternatively, we can also match the most common channel training AST pattern, and still reduce with
0.1
.Some more information from the investigation:
go mod download
).GO111MODULE=off go get -u -v github.com/mgechev/revive
.revive -exclude vendor/... -formatter friendly -config .revive.toml ./...
I’ve done 3rd step with and without network connection by applying
docker network disconnect bridge CONTAINER_NAME
. The results were the same and unstable:After ~10 (this number changes randomly) successful runs, I got the similar panic mentioned by @martin-sucha. Packages in the panic messages were different (publicly available from github and private from our internal VCS).
Also, I tried to reproduce a similar flow with
github.com/mgechev/revive
repo without success, unfortunately.Dockerfile where I tried to reproduce the error