Fix new-page database conversion race

[3mdistal]

Problem

Creating a blank Content page is optimistic: the editor opens before the initial document record has necessarily persisted. A user could choose Database during that window, see a successful-looking click, and remain on the page chooser because the conversion reached the server before the document existed.

The failure blocked the BuilderSync publishing flow, which starts by creating a Content database page.

Approach

Treat an optimistic page as pending until the create-document mutation returns its persisted record. During that interval, Content keeps ordinary page editing available but disables database conversion. Once persistence completes, the persisted document replaces the optimistic cache entry before conversion is allowed.

Database-backed workspaces retain immediate optimistic navigation even when local-file content is also present. Direct local-file-only creation keeps its existing wait-first behavior.

What changed

• Mark newly created optimistic documents as pending with an in-memory symbol that is never serialized.
• Disable the Database choice, show pending feedback, and block keyboard activation until document persistence finishes.
• Replace the optimistic per-document cache entry with the server response before invalidating or converting it.
• Apply the same lifecycle to sidebar creation and the shared create-page hook.
• Add regression coverage for delayed persistence and mixed local/database workspace behavior.
• Add a Content changelog entry for the user-visible fix.

Safety and operations

This changes only Content client-side creation state and cache coordination. It does not change schemas, credentials, Builder models, or production content, and it performs no Builder writes. The production blog-article model remains out of scope.

Verification

• Focused tests: 50 Content tests pass, covering delayed persistence, conversion gating, cache replacement, and mixed local/database workspaces.
• Static checks: Content TypeScript, formatting, and diff checks pass.
• Repository checks: At 6cbf4faa2f9d6f35f3569f655a2e2f4293d13f74, Content build, Fast tests, Content DB tests, Content parity, lint, typecheck, security, static QA, standalone Chat, scaffold installation, and the exact-head Netlify preview pass.
• Independent review: Builder review of the material diff found no high- or medium-severity issues, and repository approval is current at the exact head.
• Hosted human QA: On the exact-head preview, a request-specific create-document hold kept Page enabled and Database natively disabled with a visible spinner; pointer and Enter activation were rejected, and broad Network logging recorded zero conversion requests before release. After release and a single Database activation, exactly one create-content-database POST started after create-document completed, returned HTTP 200, and produced a loading-free usable table in 3.157 seconds without changing routes or reloading. A separate reload check preserved the page title, table, and disposable row in 5.469 seconds. Console errors and Builder-domain requests were both zero.

Review focus

• Does the pending marker remain confined to the optimistic in-memory document?
• Is the persisted document installed before every path that can enable database conversion?
• Does the local-file/database workspace distinction preserve immediate navigation without changing direct local-file-only creation?

Follow-up

Global slow-network testing exposed a separate route-transition issue: Content can show the previous route and a full editor skeleton while root-route work completes. That broader routing/revalidation behavior is tracked in a separate AN Content task and will ship in its own PR; it is not required for the persistence ordering fixed here.

[github-actions]

Here's a visual recap of what changed:

Open the full interactive recap

[builder-io-integration]

Builder reviewed your changes — looks good ✅

Review Details

Incremental Code Review Summary

The latest PR head has the same material Content changes as the previous review: optimistic pages carry an in-memory pending marker, persisted server documents replace the per-document cache entry before conversion can proceed, and the sidebar distinguishes database-backed workspaces from direct local-file-only creation. The refreshed PR description also documents hosted QA confirming the disabled Database state, blocked keyboard activation, and successful single conversion at the prior exact material head.

Two independent incremental reviews found no new confirmed issues. The pending marker remains confined to the optimistic object, the mixed workspace predicate preserves immediate navigation when a filesDatabaseId exists, and the focused regression coverage remains appropriate. No previous inline findings were open, so there were no comments to resolve or avoid resubmitting. This remains standard-risk client state and cache coordination.

Key Findings

• No high- or medium-severity issues identified.
• ✅ The updated approach is consistent across sidebar and shared create-page paths.
• ✅ Hosted QA evidence in the PR description covers the critical delayed-persistence conversion flow.

🧪 Browser testing: Skipped — browser executor sessions again had no Chrome/browser automation tools. The dev server and /content route were confirmed healthy server-side after lazy warm-up, but no visual interactions or DOM evidence could be captured.