In production, likely I won't, but in testing, I'm deleting the data and then testing again. I just

JJacob Wright In production, likely I won't, but in testing, I'm deleting the data and then te...

L

lambrospetrou•1/16/25, 7:08 PM

I have a feeling something is not understood. Why deleteAll if you are going to recreate them?

J

James•1/16/25, 7:22 PM

C

Chris Jayden•1/16/25, 9:04 PM

Lmao

Llambrospetrou I have a feeling something is not understood. Why deleteAll if you are going to ...

J

Jacob WrightOP•1/16/25, 10:41 PM

Testing. I'm clearing out the data between tests. The DO represents a single collaborative document (like a GDocs file) that stores all the changes and metadata for the document. I'm creating it, making changes, deleting it, then creating it again, making different changes, deleting it. You know, testing.

JJacob Wright In production, likely I won't, but in testing, I'm deleting the data and then te...

J

Jacob WrightOP•1/16/25, 10:42 PM

Using

this.#deleted

this.#deleted

to track if the db needs to be re-created works great.

J

Jacob WrightOP•1/16/25, 11:42 PM

And my guess is if I have

/documents/:id

/documents/:id

route to a SQLite DO that creates the schema in the constructor, then if a hacker were to spam my service with a bunch of

GET /documents/XXXXX

GET /documents/XXXXX

calls trying to find a valid document, that every one of those invalid GETs would create a new DO that wouldn't be deleted because the SQLite database would be created simply by the act of accessing it, even if it returns a 404. Is that right?

With the old storage, accessing a DO without any data in it wouldn't cause a new DO to stick around. Unless data is actually stored in the storage, there is nothing that keeps it around after access.

Does anyone have strategies to preventing this behavior? Would the right way to do it be to create the database on first write (POST) and any GETs would check if the tables exist first and 404 if they don't. I suppose this create-db-on-write behavior would also solve the other issue above where I had to track if the DO was deleted. Thanks for letting me talk it out!

Is this a known best practice? Should the examples be updated to guide people to not create the database in the constructor since any access to a non-existent DO will create a new DB file that will stick around forever?

JJacob Wright And my guess is if I have `/documents/:id` route to a SQLite DO that creates the...

1

1984 Ford Laser•1/17/25, 12:02 AM

Have some sort of auth header or something, before accessing the DO, in the preceding Worker. Return before DO stub is every created

11984 Ford Laser Have some sort of auth header or something, before accessing the DO, in the prec...

J

Jacob WrightOP•1/17/25, 12:06 AM

That keeps non-authenticated users from hacking, but not authenticated users. There's some rule about never trusting users.

1

1984 Ford Laser•1/17/25, 12:07 AM

Pretty specific attack vector, hackers intercepting an authed users session? What is your use case exactly?

11984 Ford Laser Pretty specific attack vector, hackers intercepting an authed users session? Wha...

J

Jacob WrightOP•1/17/25, 12:12 AM

Oh, no, it is just that anyone can sign up for my service (just like anyone can get a Google account) and then they'd be authed as they tried to access documents. So the only difference is that the hacker would need a username/password before hacking.

My product is a novel writing tool (dabblewriter.com), and I'm switching over from the DO kv storage to SQLite. It's pretty awesome so far. But this ... hole? I guess ... in how the SQLite DOs work stumped me. I could not worry about it for now, but I wanted to see if there has been any thought to doing this the Right Way™ and what that might be. And I'm not sure about in the colos, but locally the SQLite file gets created even if .sql.exec() is called at all, so I'm not sure if there is a way to keep DOs from hanging around if no data has been added to it.

Thanks for your suggestions @1984 Ford Laser! I appreciate the help.

1

1984 Ford Laser•1/17/25, 12:15 AM

You might wanna implement some sort of rate limiter (of which there are examples in the docs) so that users can't spam APIs. There is no right way usually with CF's stuff, you're left to your own devices. For someone's use case, creating a new db table with every constructor might be perfectly necessary. The rate limiter could also signal to you when someone is attempting to abuse the system and you can act accordingly. I am having similar thought exercises as I start to build out a proof of concept into a commercially sellable product based on DOs, trying to figure things like how to bill a customer based on DO usage for example

11984 Ford Laser You might wanna implement some sort of rate limiter (of which there are examples...

J

Jacob WrightOP•1/17/25, 12:21 AM

Yeah, my Cloudflare buildout isn't live. The live product is on Google's Firestore, but DOs will be a lot better. A rate limiter is smart. That will definitely help.

I know DO SQLite is in beta. Has this issue been considered by the DO team? Or is it really a non-issue because of how cheap mostly-empty SQLite files would be?

1

1984 Ford Laser•1/17/25, 12:23 AM

Personally I am still using the KV backend as I have zero experience with SQL and much prefer a document based storage system, which I can mostly replicate with KV. At some point I will move to SQL as it seems to be considerably cheaper, and will be able to handle more complex data setups/relationships. I am using WebSockets, with frequent writes to storage, so SQL makes much more sense
My understanding is that its a non-issue, for that reason and probably others. Any decently large commercial product would have some sort of anti abuse system in place, what that looks like would be entirely dependant on your needs and capabilities. People in here can always provide their input, its interesting seeing how others put things together

Y

yash-notion•1/17/25, 12:40 AM

I'm working on a very simple test on my worker. (i'll link the code below). What i'm confused about, is what should the URL be for the worker in my test? It's example.com in the docs and that doesn't work, I tried using the actual domains i'm deploying on as well as localhost and none worked

import { describe, it, beforeAll, afterAll, expect } from "@jest/globals"
import { unstable_dev } from "wrangler"
import type { UnstableDevWorker } from "wrangler"

describe("Worker", () => {
    let worker: UnstableDevWorker

    beforeAll(async () => {
        worker = await unstable_dev("src/worker/index.ts", {
            experimental: { disableExperimentalWarning: true },
        })
    })

    afterAll(async () => {
        await worker.stop()
    })

    it("should deny request for invalid paths", async () => {
        const cases = {
            failures: ["/", "/foo", "/foo/", "/%2F"],
        }
        for (const path of cases.failures) {
            const resp = await worker.fetch(`http://localhost:3000${path}`)
            console.log(resp)
            expect(resp.status).toBe(404)
        }
    })
})

import { describe, it, beforeAll, afterAll, expect } from "@jest/globals"
import { unstable_dev } from "wrangler"
import type { UnstableDevWorker } from "wrangler"

describe("Worker", () => {
    let worker: UnstableDevWorker

    beforeAll(async () => {
        worker = await unstable_dev("src/worker/index.ts", {
            experimental: { disableExperimentalWarning: true },
        })
    })

    afterAll(async () => {
        await worker.stop()
    })

    it("should deny request for invalid paths", async () => {
        const cases = {
            failures: ["/", "/foo", "/foo/", "/%2F"],
        }
        for (const path of cases.failures) {
            const resp = await worker.fetch(`http://localhost:3000${path}`)
            console.log(resp)
            expect(resp.status).toBe(404)
        }
    })
})

import { describe, it, beforeAll, afterAll, expect } from "@jest/globals"
import { unstable_dev } from "wrangler"
import type { UnstableDevWorker } from "wrangler"

describe("Worker", () => {
    let worker: UnstableDevWorker

    beforeAll(async () => {
        worker = await unstable_dev("src/worker/index.ts", {
            experimental: { disableExperimentalWarning: true },
        })
    })

    afterAll(async () => {
        await worker.stop()
    })

    it("should deny request for invalid paths", async () => {
        const cases = {
            failures: ["/", "/foo", "/foo/", "/%2F"],
        }
        for (const path of cases.failures) {
            const resp = await worker.fetch(`http://localhost:3000${path}`)
            console.log(resp)
            expect(resp.status).toBe(404)
        }
    })
})

import { describe, it, beforeAll, afterAll, expect } from "@jest/globals"
import { unstable_dev } from "wrangler"
import type { UnstableDevWorker } from "wrangler"

describe("Worker", () => {
    let worker: UnstableDevWorker

    beforeAll(async () => {
        worker = await unstable_dev("src/worker/index.ts", {
            experimental: { disableExperimentalWarning: true },
        })
    })

    afterAll(async () => {
        await worker.stop()
    })

    it("should deny request for invalid paths", async () => {
        const cases = {
            failures: ["/", "/foo", "/foo/", "/%2F"],
        }
        for (const path of cases.failures) {
            const resp = await worker.fetch(`http://localhost:3000${path}`)
            console.log(resp)
            expect(resp.status).toBe(404)
        }
    })
})

JJacob Wright Testing. I'm clearing out the data between tests. The DO represents a single col...

H

Hello, I’m Allie!•1/17/25, 1:49 AM

Couldn’t you force an eviction after deleting?

JJacob Wright And my guess is if I have `/documents/:id` route to a SQLite DO that creates the...

L

lambrospetrou•1/17/25, 8:53 AM

then if a hacker were to spam my service with a bunch of GET /documents/XXXXX calls trying to find a valid document, that every one of those invalid GETs would create a new DO that wouldn't be deleted because the SQLite database would be created simply by the act of accessing it, even if it returns a 404. Is that right?

My own solution to that is to only run the migrations when they are needed.
In the constructor I do all the in-memory initializations, and read from the storage to see if there is any state already to load in-memory.
The actual SQL table creation (i.e. migrations) are ran when I actually want to access the storage with a valid request. The migrations keep in-memory state when applied, and also in storage, so it's a no-op once they run and has zero cost to check them.

See example in https://github.com/lambrospetrou/rediflare/blob/main/src/durable-objects.ts#L103 and https://github.com/lambrospetrou/tiddlyflare/blob/main/src/durable-objects.ts#L93

So, these spam requests will get to your DO and you can reject them without writing.

But, as others have said it's better to reject them earlier, with rate limiting or auth, etc.

O

oscar•1/17/25, 9:23 AM

Hello! I just got this error on a deploy:

Cannot apply --delete-class migration to class 'FirebaseCache' without also removing the binding that references it [code: 10061]

Cannot apply --delete-class migration to class 'FirebaseCache' without also removing the binding that references it [code: 10061]

The DurableObjects documentation seems pretty clear:

When deleting a migration using npx wrangler deploy --delete-class <ClassName>, you may encounter this error: "Cannot apply --delete-class migration to class <ClassName> without also removing the binding that references it". You should remove the corresponding binding under [durable_objects] in wrangler.toml before attempting to apply --delete-class again.

When deleting a migration using npx wrangler deploy --delete-class <ClassName>, you may encounter this error: "Cannot apply --delete-class migration to class <ClassName> without also removing the binding that references it". You should remove the corresponding binding under [durable_objects] in wrangler.toml before attempting to apply --delete-class again.

When deleting a migration using npx wrangler deploy --delete-class <ClassName>, you may encounter this error: "Cannot apply --delete-class migration to class <ClassName> without also removing the binding that references it". You should remove the corresponding binding under [durable_objects] in wrangler.toml before attempting to apply --delete-class again.

When deleting a migration using npx wrangler deploy --delete-class <ClassName>, you may encounter this error: "Cannot apply --delete-class migration to class <ClassName> without also removing the binding that references it". You should remove the corresponding binding under [durable_objects] in wrangler.toml before attempting to apply --delete-class again.

The issue is that there already aren't any bindings to the DurableObject I'm removing + it's not referenced anywhere in the entire codebase. In fact, running CMD+F on the entire project just shows the expected two instances in my DO migrations:

[[migrations]]
tag = "v1"
new_classes = ["Job"]

[[migrations]]
tag = "v2"
new_classes = ["FirebaseCache"]

[[migrations]]
tag = "v3"
deleted_classes = ["FirebaseCache"]
new_classes = ["RPCResource"]

[[migrations]]
tag = "v1"
new_classes = ["Job"]

[[migrations]]
tag = "v2"
new_classes = ["FirebaseCache"]

[[migrations]]
tag = "v3"
deleted_classes = ["FirebaseCache"]
new_classes = ["RPCResource"]

[[migrations]]
tag = "v1"
new_classes = ["Job"]

[[migrations]]
tag = "v2"
new_classes = ["FirebaseCache"]

[[migrations]]
tag = "v3"
deleted_classes = ["FirebaseCache"]
new_classes = ["RPCResource"]

[[migrations]]
tag = "v1"
new_classes = ["Job"]

[[migrations]]
tag = "v2"
new_classes = ["FirebaseCache"]

[[migrations]]
tag = "v3"
deleted_classes = ["FirebaseCache"]
new_classes = ["RPCResource"]

Any idea what could be causing this? In order to unblock my deploy for now I'll readd the DO with an empty implementation.

Ooscar Hello! I just got this error on a deploy: ```Cannot apply --delete-class migrati...

L

lambrospetrou•1/17/25, 9:27 AM

Is the deployed worker using that class though still, or did you deploy without it at least once? Not sure if it checks the deployed worker and complains due to that.

O

oscar•1/17/25, 9:29 AM

Making sure I understand correctly: You're asking whether I ever deployed the worker without the DO implementation class but with the DO binding and the new_classes migration in my wrangler.toml?
In this case tbh not sure, might be entirely possible.

O

oscar•1/17/25, 9:31 AM

I'm gonna try to deploy the worker again with the DO implementation, binding and new_classes migration and then run another deploy removing everything at once.

O

oscar•1/17/25, 9:40 AM

Running into the same issue

Ooscar Making sure I understand correctly: You're asking whether I ever deployed the wo...

L

lambrospetrou•1/17/25, 9:50 AM

I meant to deploy without that class being a binding on any worker, so that it's not actually used when you try to delete it. Migrations I believe should always exist in your wrangler, like an immutable history of sorts.

JJacob Wright Oh, no, it is just that anyone can sign up for my service (just like anyone can ...

J

James•1/17/25, 4:02 PM

The lifecycle of the db tables on a DO are entirely in your control. There is no 'hole'.

In my case, I create a DO for each user, which includes social auth (behind a captcha as well). I manage a registry of users in a central DB, not the DO. The registry contains stub ID for each DO I manage. This part isn't necessary, but it's helpful. When a new DO is created, I run the initial migrations needed to set it up. The gate to avoid abuse in my case is that random sessions / bots can't create users so easily with a single URL. They have to create an account.

When a user makes a request against the DO, thier session cookie is part of how I map them back to their DO for subsequent requests.

There's really nothing that says a DO is tightly coupled to DB tables just because you instantiated the stub. There are many ways you can ensure the tables exist before querying them.

Llambrospetrou > then if a hacker were to spam my service with a bunch of GET /documents/XXXXX ...

J

James•1/17/25, 4:14 PM

what do you mean by zero cost to check them?

let's say I have 25 migrations run, and my DO sees intermittent traffic daily, but not enough to keep from being evicted all the time, if I check in the constructor for migrations from storage, even saving it in memory, I'm potentially adding 25 row reads to a high percentage of DO requests. Maybe I only read 5-10 rows of business data per request, my migration reads end up being more than half of my real app reads.

JJames what do you mean by zero cost to check them? let's say I have 25 migrations run...

L

lambrospetrou•1/17/25, 4:16 PM

If you see my SQLSchemaMigrations helper, I don't need to read any rows, except 1 integer at constructor time. It tracks up to which migration last succeeded, so next time, if no new migrations exist it doesn't do anything.

See https://github.com/lambrospetrou/durable-utils#readme

J

James•1/17/25, 4:23 PM

ah I see, there's an assumption that all migrations succeeded up to X, which is likely fine most of the time

JJames ah I see, there's an assumption that all migrations succeeded up to X, which is ...

L

lambrospetrou•1/17/25, 4:24 PM

what do you mean? It's not an assumption, they did succeed up to X otherwise the counter stored wouldn't be X.
if you go and modify specific migrations after they already ran once, that's on you.

J

James•1/17/25, 4:27 PM

right, its an edge case

in my case, i prefer to explicitly check for all migrations by name, but I don't check for or run migrations on every init or request, I have a failsafe which runs migratoins on schema errors, as well as a migration script to propagate migrations globally on demand or trigger then on next run. I figure migrations themselves are not something I want my DOs processing most of the time

JJames right, its an edge case in my case, i prefer to explicitly check for all migrat...

L

lambrospetrou•1/17/25, 4:27 PM

I don't think this is any different (name vs id), but anyway. As long as you are happy, we are happy

J

James•1/17/25, 4:43 PM

small thing, but why would you await the migration storage calls? ideally you want all DO SQL calls in the same request to run synch

JJames small thing, but why would you await the migration storage calls? ideally you wa...

L

lambrospetrou•1/17/25, 4:47 PM

Easier to reason about. If you add an async IO by mistake in-between your non-awaited storage operations then you might have consistency issues. If everything in your code is sync, yes you can avoid it. I prefer safe and correct code first.

Llambrospetrou I meant to deploy without that class being a binding on any worker, so that it's...

O

oscar•1/18/25, 5:53 PM

Not sure I’m following here. My initial bug happened with the DO class already having no bindings to any worker. The deleted_classes migration was rejected with the DO binding already removed.

JJacob Wright Oh, no, it is just that anyone can sign up for my service (just like anyone can ...

M

Moh•1/18/25, 11:12 PM

Not sure if plausible, but maybe you could store document IDs in a normal D1 db or KV, and validate before setting up your DO SQLite db?

M

Moh•1/18/25, 11:13 PM

Make creating a document an explicit command in your application, and you get to rate limit it, cap it etc, e.g. give users 100 documents limit, force them to delete the empty documents they used before

P

peachneo•1/19/25, 5:11 AM

has anyone else ran into "Durable Object storage is no longer accessible" in tests?

Ppeachneo has anyone else ran into "Durable Object storage is no longer accessible" in tes...

1

1984 Ford Laser•1/19/25, 5:12 AM

Are you trying to retrieve a key/value that was removed? Bit more context would be helpful

Llambrospetrou If you see my SQLSchemaMigrations helper, I don't need to read any rows, except ...

森

森@VerseLink (RW)•1/19/25, 5:13 AM

reading through the source code

森

森@VerseLink (RW)•1/19/25, 5:13 AM

await this.#_config.doStorage.put<number>(this.#_lastMigrationIDKeyName(), this.#_lastMigrationMonotonicId);

await this.#_config.doStorage.put<number>(this.#_lastMigrationIDKeyName(), this.#_lastMigrationMonotonicId);

await this.#_config.doStorage.put<number>(this.#_lastMigrationIDKeyName(), this.#_lastMigrationMonotonicId);

await this.#_config.doStorage.put<number>(this.#_lastMigrationIDKeyName(), this.#_lastMigrationMonotonicId);

森

森@VerseLink (RW)•1/19/25, 5:13 AM

shouldn't using transactionSync be enough?

森

森@VerseLink (RW)•1/19/25, 5:14 AM

since put / get is actually using special Sqlite table, and sqlite in DO is sync based, meaning there's no reason to ever await

森

森@VerseLink (RW)•1/19/25, 5:15 AM

https://developers.cloudflare.com/durable-objects/api/sql-storage/

Specifically for Durable Object classes with SQLite storage backend, KV operations which were previously asynchronous (for example, get, put, delete, deleteAll, list) are synchronous, even though they return promises. These methods will have completed their operations before they return the promise.

11984 Ford Laser Are you trying to retrieve a key/value that was removed? Bit more context would ...

P

peachneo•1/19/25, 5:18 AM

No... I'm running into a strange issue.

This works:

let ran = false;
ran = await runDurableObjectAlarm(stub) // ran = true
ran = await runDurableObjectAlarm(stub) // ran = true
ran = await runDurableObjectAlarm(stub) // ran = true
ran = await runDurableObjectAlarm(stub) // ran = true
ran = await runDurableObjectAlarm(stub) // ran = false

let ran = false;
ran = await runDurableObjectAlarm(stub) // ran = true
ran = await runDurableObjectAlarm(stub) // ran = true
ran = await runDurableObjectAlarm(stub) // ran = true
ran = await runDurableObjectAlarm(stub) // ran = true
ran = await runDurableObjectAlarm(stub) // ran = false

let ran = false;
ran = await runDurableObjectAlarm(stub) // ran = true
ran = await runDurableObjectAlarm(stub) // ran = true
ran = await runDurableObjectAlarm(stub) // ran = true
ran = await runDurableObjectAlarm(stub) // ran = true
ran = await runDurableObjectAlarm(stub) // ran = false

let ran = false;
ran = await runDurableObjectAlarm(stub) // ran = true
ran = await runDurableObjectAlarm(stub) // ran = true
ran = await runDurableObjectAlarm(stub) // ran = true
ran = await runDurableObjectAlarm(stub) // ran = true
ran = await runDurableObjectAlarm(stub) // ran = false

And this - which as far as I can tell is functionally identical.. does not work (throws the given error)

while (true) {
    let ran = await runDurableObjectAlarm(stub)
    if (!ran) {
      break
    };
}

while (true) {
    let ran = await runDurableObjectAlarm(stub)
    if (!ran) {
      break
    };
}

while (true) {
    let ran = await runDurableObjectAlarm(stub)
    if (!ran) {
      break
    };
}

while (true) {
    let ran = await runDurableObjectAlarm(stub)
    if (!ran) {
      break
    };
}

Ppeachneo No... I'm running into a strange issue. This works: ``` let ran = false; ran = ...

1

1984 Ford Laser•1/19/25, 5:19 AM

does

runDurableObjectAlarm()

runDurableObjectAlarm()

return

true

true

or a similar value?

11984 Ford Laser does `runDurableObjectAlarm()` return `true` or a similar value?

P

peachneo•1/19/25, 5:19 AM

it returns a bool indicating whether the alarm executed or not

1

1984 Ford Laser•1/19/25, 5:21 AM

instead of

while (true)

while (true)

what about

while (ran)

while (ran)

? Declare

ran

ran

as true before the first run

11984 Ford Laser instead of `while (true)` what about `while (ran)`? Declare `ran` as true before...

P

peachneo•1/19/25, 5:23 AM

same result

1

1984 Ford Laser•1/19/25, 5:23 AM

Check what the alarm is returning to make sure its a bool?

11984 Ford Laser Check what the alarm is returning to make sure its a bool?

P

peachneo•1/19/25, 5:24 AM

yeah I've checked it's definitely a bool

1

1984 Ford Laser•1/19/25, 5:25 AM

What does the alarm do? Is the error in the alarm handler itself or this other code?

P

peachneo•1/19/25, 5:26 AM

it fails on a call to storage that the callback for the alarm calls

In production, likely I won't, but in testing, I'm deleting the data and then testing again. I just

Similar Threads