Dealing with "QueryRowContext failed: sql: Rows are closed" due to context canceled
Adam Pritchard
It’s pretty common (for client reasons) for our API server to get context.Canceled errors when clients terminate their connections before server response processing is complete. We detect and treat these differently (as warnings rather than errors, in a logging sense), since they’re client triggered and don’t indicate something wrong with the running of the server. So that’s fine.
But… Every now and then the context getting canceled will first surface as a DB error, like: “QueryRowContext failed: sql: Rows are closed”. It seems like a sort of race condition as to where the canceled state is first detected.
This case looks unavoidable, but, as above, we’d still prefer to detect and downgrade it to a warning. So… Is there a robust way to do this?
The origin of the error suggests that there’s no unique error type for “rows are closed” to compare against. So, is the string used for the error considered stable enough to compare against to detect the error type?
Or maybe any DB error could fall into checking “are the rows closed?” But I don’t see an API for checking that (either in database/sql or pgx).
Or maybe any DB error could fall into checking if the context has been canceled (ctx.Err() == context.Canceled)? But that seems like it might mask real DB errors if the context was only coincidentally cancelled. Low probability of that occurring, though.
But is there a right way to do this?
Thanks in advance.
Daniel Theophanes
--
You received this message because you are subscribed to the Google Groups "golang-sql" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-sql+...@googlegroups.com.
To post to this group, send email to golan...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-sql/f9208134-0bb5-4816-8f24-a794de698e88%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.