Enhance notification validation, fallback to fallback provider when retry budget exceeds and implement SSL automation in onboard cli#11
Conversation
… channel, template_id, or content
…for current provider
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: d16306cf5c
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| if (typeof options.sslDomain === 'string') { | ||
| sslDomainValue = options.sslDomain.trim().toLowerCase(); | ||
| } else if (!isFullMode) { |
There was a problem hiding this comment.
When SSL is enabled outside --full mode, CLI-provided --ssl-domain is accepted by simple trimming/lowercasing without running validatePublicDomain, so invalid values (for example URLs, domains with ports, or malformed hostnames) pass onboarding and only fail later during Certbot execution. This makes non-interactive/partially-interactive runs fail late and unpredictably; the same validation used for prompted input should also be applied to provided flags before returning setup options.
Useful? React with 👍 / 👎.
| const fallbackNotification: BaseNotification = { | ||
| ...notification, | ||
| provider: fallbackProviderId, | ||
| }; |
There was a problem hiding this comment.
The new handoff path republishes messages with provider already set to the fallback provider; those messages are still processed through sendWithFallback, whose explicit-provider branch retries non-retryable failures via tryFallback, which resolves the configured fallback again. In the case where the current provider is already that fallback, this causes a second send attempt to the same provider for one message whenever the fallback returns retryable: false.
Useful? React with 👍 / 👎.
1 participant
No description provided.