A monitoring engineer wants an OSPF configuration snippet from twelve switches and posts the CLI commands to the Catalyst Center Command Runner endpoint, which responds with a task identifier instead of the command output. The team's policy requires the script to release the connection right away and come back for the results later. How should the script use that task identifier to retrieve the Command Runner output?
Select an answer to reveal the explanation.
Short Explanation
Command Runner queues the work, so the identifier is a claim ticket rather than the finished text. You poll the task until it reports done and then fetch the file it points to — it's like picking up an order when the kitchen calls your number.
Full Explanation
The Command Runner endpoint is an asynchronous job launcher: the request carries the commands, the device UUIDs and the response format, and Catalyst Center replies with a task identifier because it has to queue the work, open a session on each switch and gather the replies before anything becomes readable. The task record is the only handle you have, and once the job finishes its progress payload names the result file that holds the per-device output, so you poll the task until that state appears and only then download the file. Reissuing the CLI read request simply creates a second job and hands back another identifier, so you would be waiting on a fresh queue instead of reading the first one. The network-device detail endpoint returns inventory, reachability and software level rather than CLI text, so it carries no command output. Registering a callback has no effect here because this endpoint never posts results back to a caller. Caveat: a task can finish while an individual switch still reports a failure, so read each device's own entry in the downloaded file instead of trusting the overall status. Practical check: post one show command to a single lab switch, poll the task GET with a short sleep, and log both the final state and the file you download.