You cannot select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

69 lines
3.1 KiB
Markdown

+++
title = "[TRIAGE] D1 binding chicken-and-egg — D1 ID not known until after apply, but Worker needs it at plan time"
priority = 8
status = "done"
ticket_type = "task"
dependencies = []
+++
<context>
This is a triage decision ticket. It must be resolved before dependent implementation tickets can proceed.
</context>
<question>
D1 binding chicken-and-egg: the D1 database ID is not known until after `tofu apply`, but the Worker resource needs the D1 ID at plan time. How do we break this circular dependency?
</question>
<options>
1. **Two-phase apply** — apply D1 resource first, capture the output ID, then apply the Worker with the ID. Requires splitting `tofu apply` into two steps.
2. **`data` source lookup** — use a `cloudflare_d1_database` data source to look up an already-existing D1 database by name. Requires D1 to be created manually first or in a prior apply.
3. **OpenTofu `depends_on`** — express the dependency explicitly and let OpenTofu plan the two resources in the correct order. May work if the Cloudflare provider handles the reference correctly.
</options>
<decision>
**Option 3 (attribute reference) — and there is no chicken-and-egg problem.**
This is a common Terraform/OpenTofu misconception. Writing `database_id = cloudflare_d1_database.db.id` in the Worker resource creates an **implicit dependency** via the attribute reference. OpenTofu:
1. Sees that `cloudflare_workers_script.api` depends on `cloudflare_d1_database.db` (via the `.id` reference)
2. Plans D1 creation first; shows Worker `database_id` as `(known after apply)` — this is **expected and correct**
3. During `tofu apply`: creates D1 first → gets its ID from state → creates Worker with that ID
No two-phase apply, no `data` source, no explicit `depends_on`. A single `tofu apply` provisions both resources in the correct order.
Confirmed from Cloudflare provider v4 source:
- D1 resource: `cloudflare_d1_database` — outputs `id` (String)
- Worker resource: `cloudflare_workers_script` (plural) — `d1_database_binding` block with `database_id` and `name` fields
- This also confirms the answer to TRIAGE efee79: resource name is `cloudflare_workers_script`
Concrete HCL:
```hcl
resource "cloudflare_d1_database" "db" {
account_id = var.cloudflare_account_id
name = "quotesdb"
}
resource "cloudflare_workers_script" "api" {
account_id = var.cloudflare_account_id
name = "quotesdb-api"
content = filebase64("../target/wasm32-unknown-unknown/release/api.wasm")
d1_database_binding {
name = "DB"
database_id = cloudflare_d1_database.db.id # (known after apply) — resolved automatically
}
}
```
API Worker CI/CD deploy ticket: 57fe5e
</decision>
<resolution>
1. Research the options above and choose the best approach for this project.
2. Update the `infra/worker.tf` and `infra/d1.tf` resources with the chosen approach. Update ticket a23489 and d0da0b with any constraints.
3. Mark this ticket done with a note on the chosen approach in the body or a comment.
</resolution>
<commit>
`chore(quotesdb): resolve triage — d1-binding-standard-attribute-reference-no-chicken-and-egg`
</commit>