I'm writing a PowerShell script that searches devices through an MDM platform. Because the API requires a separate request for each device, processing more than 1,500 systems sequentially takes over 10 minutes. I split the devices into 10 groups and run PowerShell jobs asynchronously, which reduces the API work to about a minute.
This generally works, but occasionally a request produces a 404 error. I'm not sure whether the error should be handled inside the script block passed to Start-Job or while collecting results with Receive-Job. What is the recommended way to capture and report errors from individual API requests without losing the successful results? I'd also appreciate guidance on whether a 404 should be retried or treated as a missing or stale device.
3 Answers
A retry loop can help if the 404 is actually caused by a temporary API condition. Limit it to a small number of attempts, such as two or five, and then record the device as failed instead of retrying forever. Before doing that, confirm whether the endpoint genuinely exists; a real 404 usually means the device or resource is gone, while rate limiting is more commonly reported as 429.
Put the primary error handling inside the job’s script block, around each individual API request. Use Invoke-RestMethod with -ErrorAction Stop, then return a consistent object for every device whether the request succeeds or fails. Include fields such as DeviceId, URL, Success, StatusCode, Result, and ErrorMessage. The parent script can then receive all job output normally and filter failures afterward. Receive-Job can display errors from a job’s error stream, but handling them inside the job gives you much cleaner, per-device results.
A 404 might mean the device was removed or the original list is stale, so it probably shouldn’t be treated the same as a 429 rate-limit response or a server-side 500 error. Retry temporary failures a limited number of times, and honor Retry-After when the API provides it. If you’re using PowerShell 7, ForEach-Object -Parallel with -ThrottleLimit 10 may also be simpler than manually splitting the devices into ten arrays and starting separate jobs.
Thanks, that makes sense. I’ll try returning a success or failure object for each device and handle the retry rules based on the status code.
Keep the output from each job structured rather than relying on screen output. Collect the jobs with Receive-Job -Wait, then filter the returned objects for failures and write a separate report. Also be cautious about modifying shared arrays or hash tables from concurrent workers, since ordinary PowerShell collections aren’t thread-safe. Returning objects from each job and combining them in the parent scope avoids many synchronization problems.
Right—the correct behavior depends on what the API means by 404. If the device can actually be deleted between the initial inventory request and the follow-up request, it may be better to log it as unavailable rather than retrying repeatedly.