hashicorp / hashicorp/packer-plugin-tencentcloud
tencentcloud-cvm: intermittent "instance(...) not exist" on first build attempt, across zones and worse under parallelism
- Dominant language
- Go
- Stars
- 8
- Forks
- 11
- PR merge metrics
- No merged PRs in 30d
Description
## Overview
Packer intermittently fails on the **first** build attempt with:
```
Failed to wait for instance ready: instance(ins-...) not exist
```
This happens immediately after the plugin successfully creates the instance (`RunInstances` returns an ID), then its "wait for instance ready" `DescribeInstances` poll finds the instance gone. There is **no prior error** — it is a fresh build.
This is distinct from the earlier closed issue #6 (which was a re-run after a prior ansible failure). Here it occurs on a clean first attempt, and a **direct Tencent Cloud `RunInstances` + `DescribeInstances` (without Packer) works reliably** for the same image / instance type / zone / subnet.
## Environment
- Packer: `1.16.0` (also observed on earlier 1.x)
- Plugin: `packer-plugin-tencentcloud` **v1.2.0** (latest public release resolved by `packer init`)
- Region: `ap-guangzhou`, zones `ap-guangzhou-6` and `ap-guangzhou-7`
- Several builds run concurrently (each is its own `tencentcloud-cvm` builder / keypair)
## Reproduction / Error log
The failure is consistent and looks like (from a 16-build matrix run):
```
==> tencentcloud-cvm.default: Image found: Red Hat Enterprise Linux 9.5 64bit
==> tencentcloud-cvm.default: Trying to create a new keypair: packer_6a81df65...
==> tencentcloud-cvm.default: Trying to use existing subnet: subnet-iy8ryv84...
==> tencentcloud-cvm.default: Subnet found: subnet1
==> tencentcloud-cvm.default: Trying to use existing securitygroup: sg-j3c1b5if...
==> tencentcloud-cvm.default: Trying to create a new instance...
==> tencentcloud-cvm.default: Waiting for instance ready
==> tencentcloud-cvm.default: Failed to wait for instance ready: instance(ins-851nf8co) not exist
==> tencentcloud-cvm.default: Deleting instance because of error...
==> tencentcloud-cvm.default: Deleting keypair because of error...
Build 'tencentcloud-cvm.default' errored after 4 seconds 406 milliseconds: instance(ins-851nf8co) not exist
```
## Observations
1. **Happens on the first attempt** — the instance was just created and the plugin immediately cannot find it via `DescribeInstances`. No preceding error.
2. **Not zone-specific** — reproduced in both `ap-guangzhou-6` and `ap-guangzhou-7`.
3. **Worse under parallelism** — a 16-build matrix at 4 concurrent builds fails much more often than a single build, though single builds also fail intermittently.
4. **Direct API works** — a bare `RunInstances` + `DescribeInstances` for the same image/type/zone/subnet succeeds and the instance stays `RUNNING`. The failure is specific to the plugin's launch+wait sequence.
5. **Still occurring** — matches @Jalle19's Oct-2024 comment on the closed #6: "This is still happening. Started happening randomly while I was building various images."
## Expected behavior
The plugin should tolerate eventual-consistency in `DescribeInstances` — e.g. retry the "wait for instance ready" poll with backoff for a short window before failing — rather than aborting immediately when a just-created instance is briefly not visible. Under high concurrency this is the difference between a fully green matrix build and one that fails everything.
Contributor guide
Research direction
Start at the tencentcloud-cvm builder entry point that calls RunInstances and then waits with DescribeInstances. Reproduce a clean first build, including concurrent builds, and trace the wait sequence when the newly created instance is temporarily absent. Done means the wait tolerates eventual consistency with retries and backoff without masking a genuinely missing instance.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- cloud
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 68/100