vibed/quotesdb/.beans/quotesdb-cc35--triage-d1-binding-chicken-and-egg-d1-id-not-known.md

title	status	type	priority	created_at	updated_at
[TRIAGE] D1 binding chicken-and-egg — D1 ID not known until after apply, but Worker needs it at plan time	completed	task	critical	2026-03-10T23:32:05Z	2026-03-10T23:32:05Z

This is a triage decision ticket. It must be resolved before dependent implementation tickets can proceed. 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? 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. **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:

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

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. `chore(quotesdb): resolve triage — d1-binding-standard-attribute-reference-no-chicken-and-egg`