Agree. Let’s start with docs, since fixes to the Golang client is a bit lower priority now, and the problem might go away by itself in the C++ client depending on how we implement it.

Check out .

good catch, as it doesn't create a log file either. I had to actually dump the journal into a file.

We need to fix it, or at least mention in the docs that we can not overload the Enter of that state. What do you think?

It’s definitely the former, I believe. The client never formally concludes the deployment by reporting a status, and therefore the server keeps it open. The next time the client returns, it has already forgotten that it tried the deployment earlier, and treats it as a brand new one. This repeats over and over.

Hello ,

I produced the attached logs (endless-reboot.log) with debug enabled and my tenant token filtered out. I see like after the return 1, eventually it goes back to idle and then to download again. So my question is: do you consider the bug is in the state script handler that does not abort the deployment, or do you think the problem could be somewhere else because it looks like somehow it fails but it does not respect the “retries” and keep retrying indefinitely?

I have a different suggestion: What about dedicating a specific script return code to abort, like we do for the 21 (retry-later) functionality? So we would have 22 (abort), for example. That would have a much lower risk of breaking existing scripts, but allows us to put it in the main product. What do you think?