We occasionally observe es_mute_process_events() called on an es_client_t while an AUTH event delivered by the same client is still outstanding. In the problematic state, es_mute_process_events() stops returning inside IOConnectCallStructMethod. Subsequent calls to es_respond_flags_result() and a fallback es_respond_auth_result() on the same es_client_t also block in IOConnectCallStructMethod, eventually causing the AUTH deadline to be missed. We would like to clarify the concurrency semantics of these APIs: Is it supported to call es_mute_process_events() before responding to an outstanding AUTH event delivered by the same es_client_t? Can es_mute_process_events() wait for in-flight/outstanding AUTH processing? Are mute operations and es_respond_*() calls serialized internally for a single es_client_t? Can an in-progress mute operation prevent a concurrent es_respond_*() call from completing? Is the recommended pattern to respond to the AUTH message first and update mute state asynchronously afterward?