+++
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>