Cannot create an Issue in GitHub to report bug for k6 or xk6-tcp

Grafana k6
1

I have found a bug in xk6-tcp.

I cannot create a new issue in GitHub Grafana k6 or xk6-tcp.

GitHub replies

"Error

Unable to create issue."

Here is the bug report

xk6-tcp related panic due to nil passed as tagSet to handleError

k6 with xk6-tcp crash

panic: runtime error: invalid memory address or nil pointer dereference
atlas.(*Node).ValueByKey          atlas.go:45
metrics.(*TagSet).Get             tags.go:56
summary.(*Output).storeSample     summary.go:177   <- sample.Tags.Get(TagCheck)
summary.(*Output).flushSample     summary.go:86
summary.(*Output).flushMetrics    summary.go:79
output.(*PeriodicFlusher).run     helpers.go:69     <- runs every 200ms in its own goroutine

Suggested Patch to tcp/socket_read.go

-	e := s.handleError(err, "read", nil)
+	// currentTags() must be used here (not nil) - handleError ultimately pushes
+	// a metrics.Sample with these tags, and a nil *metrics.TagSet crashes the
+	// summary/dashboard output's periodic flusher...
+	e := s.handleError(err, "read", s.currentTags())
2

Hi @bernda01,

Thanks a lot for this — and sorry you couldn’t file it on GitHub directly. That was most likely a temporary GitHub glitch on their end, since issue creation is open to everyone on the repo and nothing is restricted on our side. Worth another try if you run into it again.

This was a genuinely good catch. The panic surfaces in k6’s periodic metric flusher with no xk6-tcp frames anywhere in the stack trace, so it’s the kind of report that’s easy to misattribute to k6 itself. You went straight to the actual cause and even pointed at the exact line — that saved us real triage time.

I’ve filed it on your behalf and credited you in the issue:

- Issue: Panic in periodic metric flusher: `nil` `TagSet` pushed on socket read error · Issue #67 · grafana/xk6-tcp · GitHub

- PR: fix: pass current tags when handling read errors by szkiba · Pull Request #68 · grafana/xk6-tcp · GitHub

The PR implements your suggested fix as-is — passing s.currentTags() instead of nil in tcp/socket_read.go — plus a regression test that drives the read loop into a connection reset and asserts the emitted tcp_errors sample carries a non-nil tag set. I verified the test fails without your one-line change, so it should keep this from coming back.

Your diagnosis was correct on every point: the nil reaches the sample’s TimeSeries.Tags via addErrorMetrics, and k6’s summary output then calls Tags.Get on it during the flush. It’s also deterministic rather than a race, io.EOF and timeout errors return earlier in the read loop, so any “real” read error (a connection reset, for instance) triggers it every time.

If filing does keep failing for you, let me know what you’re seeing — an error message, or a missing “New issue” button — and I’ll look into it.

In the meantime, a useful fallback: if you ever can’t open an issue in an extension repo (xk6-tcp, xk6-redis, xk6-kafka, and so on), just file it in the main grafana/k6 repo instead and mention which extension it concerns. We can move it to the right repo from there, so nothing gets lost. The forum works fine too, as this thread shows — but an issue is easier for us to track.

Thanks again for taking the time to track this down properly.

-i2n-

3

Thanks for the quick turnaround on this i2n..

Unfortunately I was not able to create the issue against Grafana/k6 as well as Grafana/xk6-tcp.

Probably an issue with my enterprise’s settings.