> then if a hacker were to spam my service with a bunch of GET /documents/XXXXX calls trying to find

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.

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.

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"]

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...

lambrospetrouOP•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.

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.

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.

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...

lambrospetrouOP•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 ...

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 ...

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...

lambrospetrouOP•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

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 ...

lambrospetrouOP•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.

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...

lambrospetrouOP•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

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...

lambrospetrouOP•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...

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 ...

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?

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

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...

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);

森

森@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 ...

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

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
    };
}

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

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?

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

it returns a bool indicating whether the alarm executed or not

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...

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

same result

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?

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

yeah I've checked it's definitely a bool

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?

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

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

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

So then I assume the storage you're requesting isn't there? KV storage?

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

durable object storage. Yeah I guess the storage isn't there... but the question is why lol

I mean how on earth does using a while loop that makes the exact same calls as the inlined non-loop version does result in a different outcome

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

Smells like some weird race condition to me

Ppeachneo durable object storage. Yeah I guess the storage isn't there... but the question...

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

Very odd

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

seems to be a timing issue, if I stick an arbitrary delay in the loop it passes

Niveth•1/19/25, 7:55 AM

What is the maximum time, I can set an alarm in durable object ?

NNiveth What is the maximum time, I can set an alarm in durable object ?

1984 Ford Laser•1/19/25, 9:00 AM

Maybe 03:14:07 UTC on 19 January 2038?

森森@VerseLink (RW)shouldn't using transactionSync be enough?

lambrospetrouOP•1/19/25, 9:00 AM

The KV API is async though, even though in SQlite DOs all storage operations are the same, so I am using

await

await

to be consistent with the API that you need to await a Promise. The underlying behavior doesn't change.
Someone reading the code and not seeing an

await

await

of a promise will be more confused, rather than having to read all the DO docs to figure out that it doesn't matter.

Llambrospetrou The KV API is async though, even though in SQlite DOs all storage operations are...

森

森@VerseLink (RW)•1/19/25, 9:03 AM

sounds good, yeah, I actually did notice that, I'm just thinking if the choice was intentional and if I have mistaken it or not

森

森@VerseLink (RW)•1/19/25, 9:03 AM

though, why doesn't DO expose a sync version of it under sql

森

森@VerseLink (RW)•1/19/25, 9:04 AM

i understand it's backwards compatiblity, but old DO can't migrate to sql backed DO though?

森森@VerseLink (RW)though, why doesn't DO expose a sync version of it under sql

lambrospetrouOP•1/19/25, 9:04 AM

because the KV API is the same for both types of DO, and in the non-SQLite one you actually have to await.

森

森@VerseLink (RW)•1/19/25, 9:05 AM

I'm actually writing similar migration tool myself (for internally stuff), would you say that creating a version table myself and use the sync api be better then KV API

森森@VerseLink (RW)I'm actually writing similar migration tool myself (for internally stuff), would...

lambrospetrouOP•1/19/25, 9:06 AM

There isn't better or worse. They are the same underlying storage. KV API goes to a special table that your SQL statements cannot modify, hence why I chose that. Otherwise you could mess up one of your actual migrations and delete your schema migration tracking table. Other than that separation, nothing else is different.

森

森@VerseLink (RW)•1/19/25, 9:07 AM

ah i see, thanks for the insight

森

森@VerseLink (RW)•1/19/25, 9:07 AM

I'm planning to keep track of the bookmarks when the migration happens (in case something bad happens, a rollback can be triggered immediately), so I would need an internal table to track that anyways

> then if a hacker were to spam my service with a bunch of GET /documents/XXXXX calls trying to find

Similar Threads

Similar Threads

Similar Threads