Return useful error for busy connections#1787
Conversation
Walkthrough
ChangesBusy buffer prepare handling
Author list update
Estimated code review effort: 2 (Simple) | ~10 minutes Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
How did you verify that there are no cases where ErrBusyBuffer is returned for other reasons? |
|
You're right — I had not verified that assumption globally. I traced all ErrBusyBuffer producers. It is returned by takeBuffer, takeSmallBuffer, and takeCompleteBuffer whenever the shared read buffer is non-empty, and those helpers are also used by authentication and other write paths. Therefore, the previous global error message was too specific. I pushed 4cbd816 to restore the original ErrBusyBuffer message and add cause-neutral context only in Prepare: The Prepare path is writeCommandPacketStr -> takeBuffer, so the added context reflects the verified buffer invariant without assuming that an open result set is the only possible cause. errors.Is(err, ErrBusyBuffer) is still preserved. |
Description
When a previous result set still owns the connection buffer,
Preparelogsbusy bufferand converts the error todriver.ErrBadConn. This hides the actual caller mistake.This change:
ErrBusyBufferfromPrepareinstead ofdriver.ErrBadConnAUTHORSFixes #526.
Checklist
Validation
go test ./... -run 'TestPrepareBusyBuffer|TestPrepareWithOpenRows' -count=1go vet ./...