[kwy404]

An HFP Audio Gateway built with Bumble answers a rejected AT+CHLD (unsupported operation or unknown call index) with both +CME ERROR and OK, which shifts every later response on the HF side by one command and still reports the rejected request to the application as a call_hold event.

Root cause

AgProtocol._on_chld sends +CME ERROR when the operation is not in supported_ag_call_hold_operations or when no call matches the index, but it does not return. It falls through to send_ok() and emit(EVENT_CALL_HOLD, ...). The HF treats the error as the final result of AT+CHLD, so the extra OK stays queued and becomes the result of the next command. With Bumble's own HfProtocol, a following AT+CIND? then fails with HfpProtocolError(NO ANSWER), and from there each command receives the previous command's response.

Fix

Return right after sending each error, like the invalid operation branch just above already does.

Test

test_hold_call_with_unknown_call_index in tests/hfp_test.py sends AT+CHLD=11 with no active call, expects the HfpProtocolError, then checks that a following AT+CIND? gets its own +CIND response and that no call_hold event was emitted. Before the change the second command fails with NO ANSWER; after it, the test passes. All tests in tests/hfp_test.py pass and black -S --check is clean on the changed files.