On version v4.13.0, we noticed that when dealing with context timeouts, we'd sometimes get an unexpected sql.ErrNoRows rather than the expected context error which broke some of our error handling logic.
I believe this happens when a context times out while trying to Find a specific row (bkind == kindStruct) right before rows.Next() gets called.
In this case, rows.Next() will return false and bind will return sql.ErrNoRows. This results in Query.Bind returning the error immediately without doing a rows.Err() check.
Could be addressed by either checking for rows.Err() outside the for rows.Next() or within the error handling when the call to bind returns an error.
Reproduced with a context timeout and a breakpoint before entering the for rows.Next() loop, don't have unit test that could be easily used to reproduce this specific error scenario otherwise
On version v4.13.0, we noticed that when dealing with context timeouts, we'd sometimes get an unexpected
sql.ErrNoRowsrather than the expected context error which broke some of our error handling logic.I believe this happens when a context times out while trying to Find a specific row (
bkind == kindStruct) right beforerows.Next()gets called.In this case,
rows.Next()will return false andbindwill returnsql.ErrNoRows. This results inQuery.Bindreturning the error immediately without doing arows.Err()check.Could be addressed by either checking for
rows.Err()outside thefor rows.Next()or within the error handling when the call tobindreturns an error.Reproduced with a context timeout and a breakpoint before entering the
for rows.Next()loop, don't have unit test that could be easily used to reproduce this specific error scenario otherwise