even in the do chat sample? https://github.com/cloudflare/workers-chat-demo
GitHub
Contribute to cloudflare/workers-chat-demo development by creating an account on GitHub.
message and close WS handlers, I also had a error one set up, which was supposed to remove the current connection from the list of connections, but wasn't necessarily closing the connection, such as if the client experienced an error, but not one that caused the socket to close. Somewhere, this was causing the socket to stay open or something. You can see a comparison in the screenshots

DurableObject type: https://developers.cloudflare.com/durable-objects/api/namespace/#idfromnameDUMMY_OBJECT.DurableObject is named DummyDurableObject then yes.storage.deleteAll() must be called and no SQLite tables can exist?storage.deleteAll(), and a new call comes in after that, it errors because the tables don't exist, and I don't know whether to re-create them or not. Is there a solution to this?deleteAll is called everything is deleted, including all your tables.I don't understand the question. If you decided to delete all the data for a DO, why would you want to handle a request to it and re-create the tables?
- [...] I don't know whether to re-create them or not. Is there a solution to this?
this.#deleted = true and then reinitialize the database on future requests. If the DO goes out of memory, the constructor will run again and initialize it. If it hasn't gone out of memory yet, #deleted will be true. Should work.
this.#deleted to track if the db needs to be re-created works great./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 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?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.
export default defineEventHandler(async (event) => {
try {
const env = event.context.cloudflare?.env.DUMMY_OBJECT;
const id = env.idFromName('counter');
const stub = env.get(id);
const response = await stub.fetch(event.context.cloudflare.request);
const data = await response.json() as { value: number };
return data;
}
catch (error) {
console.error(error);
return { error: 'Failed to fetch from Durable Object' };
}
});/// <reference types="@cloudflare/workers-types/2023-07-01" />
declare module "h3" {
interface H3EventContext {
cf: CfProperties;
cloudflare: {
request: Request;
// env: Env;
env: {
MY_KV: KVNamespace,
DB: D1Database,
MY_BUCKET: R2Bucket;
DUMMY_OBJECT: DurableObjectNamespace;
}
context: ExecutionContext;
};
}
}
export {};[[durable_objects.bindings]]
name = "DUMMY_OBJECT"
class_name = "DummyDurableObject"
[[migrations]]
tag = "v1"
new_classes = ["MyDurableObject"]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)
}
})
})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.[[migrations]]
tag = "v1"
new_classes = ["Job"]
[[migrations]]
tag = "v2"
new_classes = ["FirebaseCache"]
[[migrations]]
tag = "v3"
deleted_classes = ["FirebaseCache"]
new_classes = ["RPCResource"]