This is a general post, wondering if anyone has other ideas regarding how to perform actions against the destination system early(ish) in the driver starup process.

Now, this has already been solved - but the current solution I have (which builds upon work done a few years back by my colleague) has some drawbacks.

First.. the problem:

If you have policy that tries to access the connected system too early in the startup process, the policy does not execute properly.
The most common symptom is that the result of the query (instances + a status) don't get delivered to the rule which triggered the query.
Instead the instance keeps on going through subsequent policies eventually erroring out as "Code(-9042) <nds> element must contain a <input> element."

The introduction of Startup policies doesn't help at all with this scenario, it is executed far too early to be useful when you need to query the connected system.

In simple terms, the solution we've come up with is to:

1. Look for a status success which contains the text "Remote driver successfully started"
2. Set a driver-scoped variable to indicate that the connected system is up
3. Break processing.
.... delay for (at worst) the driver heartbeat interval.
4. On next heartbeat check that driver-scoped variable set in step 2 is set.
5. Now it is safe/reliable to perform Query operations against connected system.

Note that this all occurs on the publisher thread.

The issue is where the heartbeat is set to large values (especially where the driver heartbeat is used as a trigger for polling).
I've worked on drivers where the heartbeat is set to 6 hours.

Of course you can take the heartbeat down to something small during debugging - but that doesn't help so much in the bigger picture.

Now anyone know of a way to avoid the break/wait for next heartbeat step? or a different way to confirm the connected system is up and talking?