waitForReady hangs on "TObject does not exist" / nResult<0 instead of failing fast (source of false 73:1 state-0 timeouts)

[patrickoshaughnessey]

Summary

waitForReady (used by connectRoot, getObject, listObjects, and MCP fabric_status) hangs until timeoutMs when the server responds that the requested object does not exist (or any nResult < 0). The server replies immediately, but the client keeps polling for the object to reach READY and never terminates, surfacing as:

Timeout waiting for object to be ready (key: 72:4, state: 0)

This is the root cause of the "false state-0 timeouts" seen against healthy fabrics — the fabric is fine and answers; the client ignores the error and waits out the full timeout.

Evidence (raw ack frames)

[OUT event] RMTObject:update [{"twRMTObjectIx":4}] (hasAck=true)
[IN  ack  ] {"nResult":-2,"aResultSet":[[{"dwError":3,"sError":"TObject does not exist"}]]}
== ERR (after full timeout) = Timeout waiting for object to be ready (key: 72:4, state: 0)

Requesting an object that does exist returns nResult:0 with the object payload immediately and the flow completes — so the connection/transport is fine; only the not-found path hangs.

Impact

• Any read of a non-existent or deleted object index blocks for the entire timeoutMs (default 60s) instead of failing fast.
• Affects connectRoot, getObject, listObjects, and the MCP fabric_status tool — produces misleading "not ready" timeouts that read as fabric-health problems when they are not.

Suggested fix

In the read / waitForReady path, treat an ack with nResult < 0 (and/or dwError/sError "does not exist") as a terminal rejection — reject the promise with the server's error instead of continuing to poll for READY.

Repro

Request an object index that does not exist and observe the call hang for the full timeoutMs despite the immediate error ack.

Surfaced while diagnosing fabric read timeouts.