periphery trying nonstop to re-run a failing stack redeployment

[hrabbach]

Quick question whether a behaviour I'm observing is a bug or a feature. I have a server running komodo in a container and periphery via systemd. Yesterday I converted a number of old portainer stacks over to being managed in komodo (using the git integration), which seems to have worked fine, except I ran into an issue with the last stack because I had run into the docker.io pull limit. So I decided to revisit things today, since I had done a lot of pulls.

This afternoon I saw that another stack had a new version of the main image, so decided to quickly re-deploy because it also required a change to the compose.yaml. I was a bit surprised that I ran into the pull limit again, since I hadn't done any pulls the whole day. Checking the current limit, docker hub showed me 0/100 pulls still available, so clearly something was triggering the limit.

Then I looked into my logs - and was bombarded by my periphery agent running docker-compose on that failing stack over and over and over again. The only way to get it to stop is deactivating periphery entirely. I cannot seem to see anywhere how to stop it from retrying - the UI shows that the redeploy failed, but not that it's still running/retrying.

So, is that expected behaviour? Does periphery really run docker-compose over and over again on a redeploy, so that it keeps hammering the registry and causes the rate limit to never expire? Or is this a bug and something has gotten into a twist? Bonus points if someone can tell me how to get periphery sorted out again... if it means deleting something from the database, I'm comfortable doing that. Thanks for any pointers in the right direction...