Return useful error for busy connections

[ZYZ666-RGB]

Description

When a previous result set still owns the connection buffer, Prepare logs busy buffer and converts the error to driver.ErrBadConn. This hides the actual caller mistake.

This change:

• returns a wrapped ErrBusyBuffer from Prepare instead of driver.ErrBadConn
• adds cause-neutral context indicating that unread data remains on the connection
• adds regression tests covering the error and connection reuse
• adds the contributor to AUTHORS

Fixes #526.

Checklist

• Code compiles correctly
• Created tests which fail without the change
• All relevant tests pass
• Extended the README / documentation, if necessary
• Added myself / the copyright holder to the AUTHORS file

Validation

• go test ./... -run 'TestPrepareBusyBuffer|TestPrepareWithOpenRows' -count=1
• go vet ./...

[coderabbitai]

Walkthrough

mysqlConn.Prepare now preserves ErrBusyBuffer with an unread-data message. Tests cover buffered connections and transactions with open rows. The AUTHORS list gains one individual author entry.

Changes

Busy buffer prepare handling

Layer / File(s)	Summary
ErrBusyBuffer Prepare handling connection.go	mysqlConn.Prepare returns a wrapped ErrBusyBuffer when unread connection data prevents command writing.
Busy buffer behavior tests connection_test.go, driver_test.go	Tests verify direct buffered preparation failure and successful preparation after transaction rows are closed.

Author list update

Layer / File(s)	Summary
Individual author entry AUTHORS	Adds ZYZ666-RGB <1991039819 at qq.com> before the Organizations section.

Estimated code review effort: 2 (Simple) | ~10 minutes

Suggested reviewers: shogo82148

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Linked Issues check	✅ Passed	The changes satisfy #526 by returning a useful busy-connection error from Prepare and adding regression coverage.
Out of Scope Changes check	✅ Passed	No unrelated code changes are evident; the AUTHORS edit and tests align with the stated PR goals.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Title check	✅ Passed	The title clearly summarizes the main change: returning a useful error for busy connections.
Description check	✅ Passed	The description matches the changeset by explaining the busy-buffer error behavior, tests, and AUTHORS update.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[methane]

How did you verify that there are no cases where ErrBusyBuffer is returned for other reasons?

[ZYZ666-RGB]

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:

busy buffer: unread data remains on the connection

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.

[ZYZ666-RGB]

Hi @methane, just following up on the update in 4cbd816. I restored the general ErrBusyBuffer message, kept the Prepare context cause-neutral, and preserved errors.Is behavior. Please let me know if you would like any additional tests or changes. Thanks!

[methane]

First of all, I don't think it's a good idea to make only the Prepare error messages user-friendly. What about Exec? Query?

And I also need to consider whether error wrapping is necessary by checking all the occurrence patterns of ErrBusyBuffer. If we can solve it by just improving the basic message of ErrBusyBuffer a little, we should do that.

However, I am not going to investigate, think about, or make a decision on that right now. This issue is very low priority for me.

[ZYZ666-RGB]

Thanks for the clarification. I understand that improving only the Prepare path would be inconsistent if ErrBusyBuffer can also surface through Exec, Query, and other paths. I will avoid pushing further changes until the preferred scope is clearer. If helpful, I would be happy to audit all ErrBusyBuffer call paths and summarize the possible behaviors and trade-offs.