You’re hitting a pretty obscure edge case here. If you note from the client log, you’re getting a parameter substitution error during downloads, before the action has even begun to execute.
During the download phase, the client parses every piece of relevance in the action just in case that’s required for any downloads logic. But at this point, before execution, you haven’t yet created the output folder or log file, so you’ll get a “Singular Expression” error and the action won’t begin.
You could change all of your relevance substitutions to error-handle missing files or folders, but the easiest workaround is to include a Prefetch Block in the action, even if the block is empty. With a Pretch Block, the action only parses that block during the download phase, the rest of the relevance is not substituted until the action executes.
That said, this whole workflow you’re still trying to build is problematic. It depends on sending REST API credentials down to the client, with all the problems that secure credential storage entails. It’s risky from a security perspective. It also depends on the client having network access back to the root server so it can use those credentials - and in most cases your client should not have direct access to the root, as that exposes the server attack surface.
Instead you should use Server Automation or your own REST API calls from a dedicated server to send the action to clients, poll the server to wait for the action status, and then send a second action to client2. It’s easier to protect the credential and protect access to the root server if all the connections are coming from one machine instead of coming from any random client.
We do have a Professional Services organization as well that builds custom utilities, automations, and workflows like this under contract. Let me know if you’d like contract info to engage with them to build tools to your needs.