Target: 0.2.0.
Problem
Every long-running operation uses a hardcoded timeout with no way for a user to change it:
| Constant |
Value |
defaultDeploymentTimeout |
1 hour |
defaultTLSTimeout |
30 minutes |
defaultEMQXTimeout |
1 minute |
Observed deployment create and stop operations fit inside the current deployment timeout, but a busy region or larger deployment cannot be accommodated by users if it does not. The one-minute ceiling on Deployment API resources is tighter because waitForRemote waits for the remote object to match the configuration.
Suggested scope
Adopt the conventional Terraform timeouts block, defaulting to the current values so existing behavior is unchanged:
resource "emqxcloud_deployment" "example" {
# ...
timeouts {
create = "90m"
update = "30m"
}
}
github.com/hashicorp/terraform-plugin-framework-timeouts would be a new direct dependency and requires justification under .codex/rules/provider-development.md.
This changes externally visible behavior, so it requires a confirmed development document first, per AGENTS.md.
Target: 0.2.0.
Problem
Every long-running operation uses a hardcoded timeout with no way for a user to change it:
defaultDeploymentTimeoutdefaultTLSTimeoutdefaultEMQXTimeoutObserved deployment create and stop operations fit inside the current deployment timeout, but a busy region or larger deployment cannot be accommodated by users if it does not. The one-minute ceiling on Deployment API resources is tighter because
waitForRemotewaits for the remote object to match the configuration.Suggested scope
Adopt the conventional Terraform
timeoutsblock, defaulting to the current values so existing behavior is unchanged:github.com/hashicorp/terraform-plugin-framework-timeoutswould be a new direct dependency and requires justification under.codex/rules/provider-development.md.This changes externally visible behavior, so it requires a confirmed development document first, per
AGENTS.md.