When Publishing a runbook that runbook refences unpublished runbooks, an error should be returned and the runbook should not be published.
In nascent scenarios, the Draft & Published states of runbooks are a useful - if not required - mechanism for making and testing progressive changes to runbooks without interrupting working-state automation.
However, in mature scenarios, this scaffolding does not provide a very robust mechanism for gating changes, and does not provide an external contract to consumers that adheres to the restrictions it seemingly arbitrarily implies during execution.
The canonical example is parent/child dependency. If this is a caveat that must exist, and if during the process of Publishing, a list of referenced runbooks is built up for whatever reason (presumably to know what assets need to be pushed to a worker and to avoid doing that every execution), then if, at that time, the system knows any of those runbooks do not exist (in a published state), then the Publish should fail, returning an exception.
The exception would not need to be explicit as to what the cause was, but there seems little reason to exclude it.
I can't think of a reason why a user would want to publish a runbook that is known at that time to not be able to run successfully.
Alternatively, in lieu of returning an exception in this scenario, the seemingly arbitrary (because, as implemented, it's a runtime error) must-be-published-first rule could simply go away, because there is nothing to protect the user from putting a runbook in that state.
Thanks for this feedback!