An engineer submits three show commands for forty Catalyst Center-managed switches in one Command Runner request and immediately receives only a task identifier. The switches respond at different speeds, and the output feeds a compliance report later. Which Command Runner workflow collects the command output for the report?
Select an answer to reveal the explanation.
Short Explanation
The Command Runner is asynchronous on purpose, so your script treats the task identifier as a ticket it cashes in later. It's like a cloakroom claim check — the tag is not the coat. Poll the task resource until it finishes, then fetch the file it names.
Full Explanation
Catalyst Center, renamed from DNA Center, runs command execution as a background job, so the submit call returns a task identifier rather than output. The task resource is the status page for that job: while work is pending it reports an in-progress state, and when it completes the payload carries a file identifier pointing at the stored command output. Your script therefore needs two moves: poll until the task reports completion, then request the file resource to parse what it returns. Reading command output inline from the status response assumes a reply shape the API does not send. Waiting a fixed interval instead of polling can treat devices with different response times as if they finished together, risking incomplete results. Using the task identifier as the file reference confuses the job number with the document that job produced, because the completed task names a separate file id. Caveat: field names inside the task payload have shifted between releases, so validate the response shape on your own cluster. Practical check: log the task identifier, poll it with a timeout, and print the file identifier before downloading.