[Feature] 增加重试循环

[bigsk05]

Description / 功能描述

在出现包含 xxxxx 关键词或不包含 xxxx 关键词的情况下，继续重试，失败一次就捕获并扣除次数
所有次数扣完或触发跳过关键词时，则退出，期间发生的错误照样输出，但不中断执行流程

Motivation / 请求动机

希望在流程中增加循环重试功能，允许用户主动在清楚知晓风险的情况下设置重试
例如有时候 NS 验证签发证书会因为网络波动失败，此时手动重新执行 1-3 次即可正常
但是这对于 cron 来说很麻烦，而且属于可以接受的重试，用户在自己清楚需求的情况下设置一个重试次数
我自己在使用中这是一个高频需求场景，我目前的解决办法就是自己手动重新执行整个流程

Miscellaneous / 其他

No response

Contribution / 贡献代码

• I am interested in contributing a PR for this! / 我乐意为此提交代码并发起 PR！

[Issues-translate-bot]

Bot detected the issue body's language is not English, translate it automatically. 👯👭🏻🧑‍🤝‍🧑👫🧑🏿‍🤝‍🧑🏻👩🏾‍🤝‍👨🏿👬🏿

---

Title: [Feature] Add retry loop

Description / Function description

In the case of a keyword that contains the xxxxx keyword or does not contain the xxxx keyword, continue to try again. If it fails once, it will be captured and the number of times will be deducted.
When all times are deducted or the skip keyword is triggered, it will exit. Errors that occurred during the period will still be output, but the execution process will not be interrupted.

Motivation / Request motivation

It is hoped that a loop retry function will be added to the process, allowing users to proactively set retries with a clear understanding of the risks.
For example, sometimes NS verification and issuance of certificates will fail due to network fluctuations. In this case, manually re-executing it 1-3 times can be normal.
But this is very troublesome for cron, and it is an acceptable retry. Users can set a retry count if they know their needs clearly.
This is a high-frequency demand scenario in my own use. My current solution is to manually re-execute the entire process myself.

Miscellaneous / Other

No response

Contribution / Contribute code

• I am interested in contributing a PR for this! / I am happy to submit code and launch a PR for this!

[fudiwei]

无脑重新下订单是不对的，ACME 协议不鼓励这么做。上游 go-acme/lego 本身已经在允许的情况下做了大量的重试了（按我的理解你指的是订单状态已经变为 invalid 了的这种失败、而不是说有个 HTTP 请求没发出去的这种），如果你真的还高频出现失败，那么大概率是配置有问题，重新走一遍下订单的流程哪怕偶尔走通了，那也是治标不治本的，你应该想办法分析具体原因：是连不上 CA 的服务器？是 NS 的问题？是 DNS 传播的问题？还是别的什么？

而且按 LE 的速率限制，相同标识符（即域名）的订单 1 小时内最多只允许失败 5 次 —— 然后就会限速了。你真的要把宝贵的重试机会浪费在无脑重试上吗？

[Issues-translate-bot]

Bot detected the issue body's language is not English, translate it automatically. 👯👭🏻🧑‍🤝‍🧑👫🧑🏿‍🤝‍🧑🏻👩🏾‍🤝‍👨🏿👬🏿

---

It is wrong to place new orders without thinking and is discouraged by the ACME protocol. The upstream go-acme/lego itself has done a lot of retries with permission (according to my understanding, you are referring to the failure where the order status has changed to invalid, rather than the failure of an HTTP request that was not sent out). If you really have frequent failures, then there is a high probability that there is a configuration problem. Go through the order process again, even if it occasionally works, it will only cure the symptoms, not the root cause. You should find a way to analyze the specific reasons: it is not possible to connect to the CA. server? Is it a problem with NS? Is it a DNS propagation issue? Or something else?

Moreover, according to LE's rate limit, orders with the same identifier (i.e. domain name) are only allowed to fail a maximum of 5 times within an hour - and then the rate will be limited. Do you really want to waste precious retry opportunities on mindless retries?

[bigsk05]

无脑重新下订单是不对的，ACME 协议不鼓励这么做。上游 go-acme/lego 本身已经在允许的情况下做了大量的重试了（按我的理解你指的是订单状态已经变为 invalid 了的这种失败、而不是说有个 HTTP 请求没发出去的这种），如果你真的还高频出现失败，那么大概率是配置有问题，重新走一遍下订单的流程哪怕偶尔走通了，那也是治标不治本的，你应该想办法分析具体原因：是连不上 CA 的服务器？是 NS 的问题？是 DNS 传播的问题？还是别的什么？

而且按 LE 的速率限制，相同标识符（即域名）的订单 1 小时内最多只允许失败 5 次 —— 然后就会限速了。你真的要把宝贵的重试机会浪费在无脑重试上吗？

我的这个功能是有一个前提条件的，即因为部署环境本身的问题导致的连接错误，此时请求甚至还未到达 DNS 服务商的端点或证书服务商的端点。
我此处也做了特别的约束说明，即一般情况下不推荐这么做，可以为用户提供这个功能，但是在添加这部分流程之前，弹出一定的警告内容，警告用户重试不适合所有场景，需要自行进行斟酌。
我也在第一部分内容里提到了，在我的部署场景下，会频繁发生 DNS 服务商处的 API 连接错误，甚至还未走到证书服务商的请求部分，这部分的重试我觉得是完全可以被接受的，事实情况下是，我一般在手动重启整个流程 1-3 次后即可成功部署，虽然这个问题在目前版本下可以通过 1-3 天的定时任务重新执行解决。
但是我觉得提供一个重试机制是好的，只是需要告知清楚该功能的风险，尤其是不适合用在 ACME 申请这一个步骤上，如果是 ACME 端点的报错，则通过我提到的关键词来判断是否应该结束重试。

[Issues-translate-bot]

Bot detected the issue body's language is not English, translate it automatically. 👯👭🏻🧑‍🤝‍🧑👫🧑🏿‍🤝‍🧑🏻👩🏾‍🤝‍👨🏿👬🏿

---

It is wrong to place new orders without thinking, and the ACME protocol does not encourage this. The upstream go-acme/lego itself has done a lot of retries with permission (according to my understanding, you are referring to the failure where the order status has changed to invalid, rather than the failure of an HTTP request that was not sent out). If you really have frequent failures, then there is a high probability that there is a configuration problem. Go through the order process again, even if it occasionally works, it will only cure the symptoms, not the root cause. You should find a way to analyze the specific reasons: it is not possible to connect to the CA. server? Is it a problem with NS? Is it a DNS propagation issue? Or something else?

Moreover, according to LE's rate limit, orders with the same identifier (i.e. domain name) are only allowed to fail a maximum of 5 times within an hour - and then the rate will be limited. Do you really want to waste precious retry opportunities on mindless retries?

This function of mine has a prerequisite, which is a connection error caused by problems in the deployment environment itself. At this time, the request has not even reached the endpoint of the DNS service provider or the endpoint of the certificate service provider.
I have also made a special constraint statement here, that is, it is not recommended to do this under normal circumstances. This function can be provided to users, but before adding this part of the process, a certain warning content will pop up to warn users that retrying is not suitable for all scenarios and needs to be considered by themselves.
I also mentioned in the first part that in my deployment scenario, API connection errors at the DNS service provider frequently occur, even before reaching the request part of the certificate service provider. I think retrying this part is completely acceptable. In fact, I usually successfully deploy after manually restarting the entire process 1-3 times, although this problem can be solved by re-executing the scheduled task in 1-3 days in the current version.
However, I think it is good to provide a retry mechanism, but the risks of this function need to be clearly informed, especially if it is not suitable for use in the ACME application step. If an error is reported by the ACME endpoint, use the keywords I mentioned to determine whether the retry should be terminated.

[fudiwei]

会频繁发生 DNS 服务商处的 API 连接错误

哪个提供商？是什么样的连接错误？

[Issues-translate-bot]

Bot detected the issue body's language is not English, translate it automatically. 👯👭🏻🧑‍🤝‍🧑👫🧑🏿‍🤝‍🧑🏻👩🏾‍🤝‍👨🏿👬🏿

---

API connection errors at DNS service providers frequently occur

Which provider? What kind of connection error is it?

[bigsk05]

我倒是没找到我举的这个例子，找到了一个消息推送失败，因为网络波动：

#YGrfQhA7DmjmjwufDxU38 部署
[2026-07-02 17:15:00]
ready to deploy certificate ...
[2026-07-02 17:15:00]
found last node output #pdwfu9i0b8iiwxr record
[2026-07-02 17:15:00]
re-deploy, because the configuration item 'ProviderConfig' changed
[2026-07-02 17:15:00]
sdk request 'WebsiteSSLSearch'
[2026-07-02 17:15:00]
ssl certificate already exists
[2026-07-02 17:15:00]
ssl certificate uploaded
[2026-07-02 17:15:00]
found websites to deploy
[2026-07-02 17:15:01]
sdk request 'WebsiteHttpsGet'
[2026-07-02 17:15:02]
sdk request 'WebsiteHttpsPost'
[2026-07-02 17:15:02]
deployment completed
#7fadYIq7wUnKw65w_dBq 推送通知
[2026-07-02 17:15:02]
ready to send notification ...
[2026-07-02 17:15:08]
could not send notification
[2026-07-02 17:15:08]
webhook error: unexpected status code: 525 (resp: )

SSL 握手失败了，重试一次就好了，这种场景会比较实用，同理的，可能部署环境的网络问题会导致这种情况发生，可以提供一个重试机制，允许用户自己做出选择，同时不建议在 acme 上使用。

[fudiwei]

可以考虑给 Webhook 针对性的增加重试（例如 5XX 时按指数退避重试） 🤔

[Issues-translate-bot]

Bot detected the issue body's language is not English, translate it automatically. 👯👭🏻🧑‍🤝‍🧑👫🧑🏿‍🤝‍🧑🏻👩🏾‍🤝‍👨🏿👬🏿

---

You can consider adding targeted retries to Webhook (for example, retrying according to exponential backoff when 5XX) 🤔

[bigsk05]

可以考虑给 Webhook 针对性的增加重试（例如 5XX 时按指数退避重试） 🤔

不错的主意，但是我其实更希望得到一个可以直接放进流程里面的重试块 🧐

[Issues-translate-bot]

Bot detected the issue body's language is not English, translate it automatically. 👯👭🏻🧑‍🤝‍🧑👫🧑🏿‍🤝‍🧑🏻👩🏾‍🤝‍👨🏿👬🏿

---

You can consider adding targeted retries for Webhook (for example, retrying with exponential backoff when 5XX) 🤔

Not a bad idea, but I would actually like to have a retry block that can be put directly into the process 🧐