Observed during the 2026-07-06 live smoke test on wrangler 4.69: pnpm run deploy auto-provisioned D1 (uuid 0985ad2b…) and used it for that deploy + remote migrations successfully, but did NOT write database_id back into wrangler.toml. Teardown then needed the id injected manually to resolve the remote DB.
Impact: unclear whether a second pnpm run deploy from the same clone reuses the DB (server-side binding association) or provisions a duplicate. Button-deploy is unaffected (each deployer gets a fresh copy).
Action: on the next deploy, verify a repeat deploy reuses the same DB; if not, either upgrade the pinned/dev wrangler (write-back improved after 4.69) or document a one-time wrangler d1 create proof + paste-id step for CLI self-hosters who deploy repeatedly. Non-blocking; the one-click and first-CLI-deploy paths both work.
🤖 Generated with Claude Code
Observed during the 2026-07-06 live smoke test on wrangler 4.69:
pnpm run deployauto-provisioned D1 (uuid 0985ad2b…) and used it for that deploy + remote migrations successfully, but did NOT writedatabase_idback intowrangler.toml. Teardown then needed the id injected manually to resolve the remote DB.Impact: unclear whether a second
pnpm run deployfrom the same clone reuses the DB (server-side binding association) or provisions a duplicate. Button-deploy is unaffected (each deployer gets a fresh copy).Action: on the next deploy, verify a repeat deploy reuses the same DB; if not, either upgrade the pinned/dev wrangler (write-back improved after 4.69) or document a one-time
wrangler d1 create proof+ paste-id step for CLI self-hosters who deploy repeatedly. Non-blocking; the one-click and first-CLI-deploy paths both work.🤖 Generated with Claude Code