> ## Documentation Index
> Fetch the complete documentation index at: https://docs.kinetica.com/llms.txt
> Use this file to discover all available pages before exploring further.

# probe_current_cluster_multi_head

[Source](https://github.com/kineticadb/kinetica-api-rust/blob/master/crates/gpudb-api/src/gpudb.rs#L2948-L2953)
pub async fn [probe\_current\_cluster\_multi\_head](https://docs.kinetica.com/content/api/rust/gpudb/struct.Kinetica/probe-current-cluster-multi-head.md#method.probe_current_cluster_multi_head)(\&self) -> [bool](https://doc.rust-lang.org/1.98.1/std/primitive.bool.html)

Re-reads the current cluster’s worker rank addresses from that cluster’s own system properties and records whether multi-head operations are usable there.This is a **capability probe**, not a health check: a cluster whose head node is up is usable whatever its workers are doing, and the answer here only decides multi-head versus head-node-only. Callers in the failover path must not treat `false` as a reason to reject the cluster — doing so kills a failover to a cluster that would have accepted the work through its head node.The refresh matters because the cluster list is populated once during connection setup and never refreshed per failover; without it the probe would validate a construction-time snapshot of a topology that may have moved since.Resolves addresses with the connection’s hostname regex, never a caller’s. What this writes — the cluster’s worker addresses and whether multi-head is available there — is connection-scoped state that every multi-head object reads, so letting one object’s filter decide it would let that object’s address selection determine a fact about the cluster for all of them.

##### Returns

Whether multi-head operations are available on the current cluster.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.