SNOW-232720: panic: send on closed channel goroutine gosnowflake/rows.go:379

[veqryn]

Issue description

panic: send on closed channel goroutine 327667 [running]: github.com/snowflakedb/gosnowflake.downloadChunk(0xc00c0f5040, 0x0) /go/src/github.com/validityhq/seeds/vendor/github.com/snowflakedb/gosnowflake/rows.go:379 +0x124 created by github.com/snowflakedb/gosnowflake.(*snowflakeChunkDownloader).schedule /go/src/github.com/validityhq/seeds/vendor/github.com/snowflakedb/gosnowflake/rows.go:253 +0x79

Example code

We were running a simple select statement:

query := sq.StatementBuilder.PlaceholderFormat(sq.Question).Select(`
		 ACCOUNT_OBJECT_ID as "ACCOUNT_OBJECT_ID"
		,CIO_ACCOUNT as "CIO_ACCOUNT"
		,CIO_ACCOUNT_EMAIL_ACCOUNT_ID as "CIO_ACCOUNT_EMAIL_ACCOUNT_ID"
		,DKIMRESULT as "DKIMRESULT"
		,MESSAGEMETA_AUTHSTATUS as "MESSAGEMETA_AUTHSTATUS"
		,EVENT_TYPE as "EVENT_TYPE"
		,HEADERAUTHENTICATIONRESULTS as "HEADERAUTHENTICATIONRESULTS"
		,INITIAL_STATE as "INITIAL_STATE"
		,COALESCE(INITIAL_STATE_CLASSIFIED_INBOX, INITIAL_STATE_IS_INBOX) as "INITIAL_STATE_CLASSIFIED_INBOX"
		,COALESCE(INITIAL_STATE_CLASSIFIED_SPAM, INITIAL_STATE_IS_SPAM) as "INITIAL_STATE_CLASSIFIED_SPAM"
		,INITIAL_STATE_IS_GMAIL_CATEGORY_FORUMS as "INITIAL_STATE_IS_GMAIL_CATEGORY_FORUMS"
		,INITIAL_STATE_IS_GMAIL_CATEGORY_PERSONAL as "INITIAL_STATE_IS_GMAIL_CATEGORY_PERSONAL"
		,INITIAL_STATE_IS_GMAIL_CATEGORY_PRIMARY as "INITIAL_STATE_IS_GMAIL_CATEGORY_PRIMARY"
		,INITIAL_STATE_IS_GMAIL_CATEGORY_PROMOTIONS as "INITIAL_STATE_IS_GMAIL_CATEGORY_PROMOTIONS"
		,INITIAL_STATE_IS_GMAIL_CATEGORY_SOCIAL as "INITIAL_STATE_IS_GMAIL_CATEGORY_SOCIAL"
		,INITIAL_STATE_IS_GMAIL_CATEGORY_UPDATES as "INITIAL_STATE_IS_GMAIL_CATEGORY_UPDATES"
		,HEADERSDKIMSIGNATURE_0_DKIMDOMAIN as "HEADERSDKIMSIGNATURE_0_DKIMDOMAIN"
		,MESSAGEMETA_FEEDKEY as "MESSAGEMETA_FEEDKEY"
		,MESSAGEMETA_SOURCEIP as "MESSAGEMETA_SOURCEIP"
		,MESSAGEMETA_MESSAGESIGNATURE as "MESSAGEMETA_MESSAGESIGNATURE"
		,METADATA_SMARTSEEDS_DOMAIN_ENGAGEMENT as "METADATA_SMARTSEEDS_DOMAIN_ENGAGEMENT"
		,SENDEREPOCH as "SENDEREPOCH"
		,HEADERDATEEPOCH as "HEADERDATEEPOCH"
		,HEADERMESSAGEID as "HEADERMESSAGEID"
		,SPFRESULT as "SPFRESULT"
		`).
		From("SMARTSEED_MESSAGE_CREATION").
		Where(sq.Eq{"MESSAGEMETA_MESSAGESIGNATURE": messageSignature}).
		Where(sq.GtOrEq{"REC_TIMESTAMP": start.UTC()}).
		Where(sq.Lt{"REC_TIMESTAMP": end.UTC()})

	sql, args, err := query.ToSql()
	if err != nil {
		return nil, errors.WithMessage(err, "Unable to convert query to sql")
	}

	result := []SmartseedMessageCreation{}
	err = db.conn.SelectContext(ctx, &result, sql, args...)

This select statement has been run successfully many many times, and we only have 1 panic in our logs.

Configuration

Driver version: github.com/snowflakedb/gosnowflake v1.3.6

Go version: 1.14

Server version: 4.39.7

Client OS: dockerized linux, on a linux host

[veqryn]

Got it again a few more times.

panic: send on closed channel

goroutine 32692447 [running]:
github.com/snowflakedb/gosnowflake.downloadChunk(0xfd1cc0, 0xc00ce05140, 0xc005a94c60, 0x1)
	/go/src/github.com/validityhq/seeds/vendor/github.com/snowflakedb/gosnowflake/rows.go:395 +0x22d
created by github.com/snowflakedb/gosnowflake.(*snowflakeChunkDownloader).schedule
	/go/src/github.com/validityhq/seeds/vendor/github.com/snowflakedb/gosnowflake/rows.go:264 +0x8b

[sfc-gh-jbahk]

@veqryn Although I am unable to directly reproduce this error, I believe this has been addressed by the 1.3.9 release of this driver (although at the current time of writing, the newest release is 1.3.12). Would you consider upgrading your driver and letting me know?

[veqryn]

I can confirm I still receive this error with version v1.3.11 of the snowflake driver.

[sfc-gh-dszmolka]

there have been many releases of the driver since the original issue submission, and even during the original submission time, we could not reproduce this issue.

would it be please possible to upgrade to the latest version of the connector (v1.6.19 at the time of writing) and if you're still seeing this error, please provide us with a minimal viable executable code which when run, can lead to the issue. thank you in advance !

as mentioned, it does not just simply happen on every execution so there might be other factors at play here. every bit of information would be helpful! e.g. when certain number of minutes/hours passes between 2 queries, or certain number of queries are fired in parallel, and so on.