Skip to content

feat: add support for D1 bookmarks to fight stale data returned from replicas - #813

Draft
kossnocorp wants to merge 3 commits into
mainfrom
fix/783-d1-bookmark
Draft

kossnocorp wants to merge 3 commits into
mainfrom
fix/783-d1-bookmark

Conversation

@kossnocorp

Copy link
Copy Markdown
Contributor

This PR closes #783.

🚧 This is rough implementation with some questionable API decisions, but it works. Opening it in case someone can have some insight on the problem.

In cases where primary D1 is deployed to say WEUR but the nearest edge is SIN right after write, the SIN replica might not get the update fast enough and the user will see data before edits.

Unless you're in Europe, where the primary D1 is deployed, you can see the problem in the playground (you might not have the access, ping me): https://voidzero-void-d1-bookmarks.skoss-individual-account.workers.dev/without-bookmark?experiment=immediate&trials=20&pressure=0.5&size=0.5&probes=20

To reproduce:

  1. In "Read-only routing baseline" section click "Run probes" button. Repeat until you see the replica region closest to you (replica / APAC / SIN in my case:

    image
  2. Then go a section below "Write/read experiment" and set:

    • Read timing: Immediate server read
    • ✅ Add replication pressure
    • Pressure per trial: 512 KiB
    • Trials: 20
  3. Press "Run Trials" button. Unless you're unlucky or D1 got significant replication pressure and switched from replica to the primary D1, you'll see some of the requests getting stale data (stale data is only possible on a replica, SIN in my case):

image

Depending on your region and current state of D1 instance you might not see stale data at all. If you see that read target is primary / WEUR wait for a 1-2 minutes and start from 1. You can also increase replication pressure a bit. A high pressure makes D1 switch to primary and only hit replicas occasionally. Most likely you will encounter a network error caused by D1 being overwhelmed.


The working solution is on the "Manual bookmark" page where data is always fresh: https://voidzero-void-d1-bookmarks.skoss-individual-account.workers.dev/with-bookmark?experiment=immediate&trials=20&probes=20&pressure=0.5&size=0.5

image

@socket-security

Copy link
Copy Markdown

Review the following changes in direct dependencies. Learn more about Socket for GitHub.

Diff Package Supply Chain
Security
Vulnerability Quality Maintenance License
Addedhono@​4.13.171001009796100
Addedcf@​1.0.0-beta.281001009999100

View full report

@cloudflare-workers-and-pages

Copy link
Copy Markdown

🚀 Deploying Preview to Cloudflare 🚀

Preview URL: https://fix-783-d1-bookmark-void-cloud.voidzero-docs.workers.dev (commit b8f635e)

This URL reflects your latest Preview deployment

Preview Deployments by commit

Status Deployment URL Commit Updated (UTC) See this deployment's details
  • Build: Success ✅
  • Deployment: Success ✅

View logs ↗
https://d9d1e272-void-cloud.voidzero-docs.workers.dev b8f635e 2026-11-13T10:07:54.715Z Visit the dashboard ↗

'export declare function setSession(start: D1SessionConstraint | D1SessionBookmark): void;',
`export declare function getBookmark(client?: ${type}<${schemaType}>): D1SessionBookmark | null;`,
]
: []),

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is clearly wrong, not all sqlite will have this API, but I didn't have time to figure out what is the best approach here.

Ideally we should know if we're running D1 or not and only then generate types, but maybe there's a cleaner solution like void/d1 or something like that.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

void/db can't carry a D1 bookmark across requests

1 participant