Any thing similar to D1 "Export an existing D1 database" (https://developers.cloudflare.com/d1/best

F

hey all! I am having issues with durable objects tests using vitest. They work fine locally, but once we run them using GitHub actions we are running into the following problem:

packages/platform-core test: Failed to pop isolated storage stack frame in tests/do/do.test.ts's test "should append events to new stream".
packages/platform-core test: This usually means your Worker tried to access storage outside of a test, or failed to cleanup storage passed across an RPC boundary.
packages/platform-core test: In particular, we were unable to pop Durable Objects storage.
packages/platform-core test: Ensure you `await` all `Promise`s that read or write to these services, and make sure you use the `using` keyword when passing data across JSRPC. See https://developers.cloudflare.com/workers/runtime-apis/rpc/lifecycle#explicit-resource-management for more details.

packages/platform-core test: Failed to pop isolated storage stack frame in tests/do/do.test.ts's test "should append events to new stream".
packages/platform-core test: This usually means your Worker tried to access storage outside of a test, or failed to cleanup storage passed across an RPC boundary.
packages/platform-core test: In particular, we were unable to pop Durable Objects storage.
packages/platform-core test: Ensure you `await` all `Promise`s that read or write to these services, and make sure you use the `using` keyword when passing data across JSRPC. See https://developers.cloudflare.com/workers/runtime-apis/rpc/lifecycle#explicit-resource-management for more details.

packages/platform-core test: Failed to pop isolated storage stack frame in tests/do/do.test.ts's test "should append events to new stream".
packages/platform-core test: This usually means your Worker tried to access storage outside of a test, or failed to cleanup storage passed across an RPC boundary.
packages/platform-core test: In particular, we were unable to pop Durable Objects storage.
packages/platform-core test: Ensure you `await` all `Promise`s that read or write to these services, and make sure you use the `using` keyword when passing data across JSRPC. See https://developers.cloudflare.com/workers/runtime-apis/rpc/lifecycle#explicit-resource-management for more details.

packages/platform-core test: Failed to pop isolated storage stack frame in tests/do/do.test.ts's test "should append events to new stream".
packages/platform-core test: This usually means your Worker tried to access storage outside of a test, or failed to cleanup storage passed across an RPC boundary.
packages/platform-core test: In particular, we were unable to pop Durable Objects storage.
packages/platform-core test: Ensure you `await` all `Promise`s that read or write to these services, and make sure you use the `using` keyword when passing data across JSRPC. See https://developers.cloudflare.com/workers/runtime-apis/rpc/lifecycle#explicit-resource-management for more details.

has anyone run into this before? I have literally tried every single combination for concurrency and isolation model and I am still running into this.

ᴀ

ᴀkqj•2/7/25, 10:19 PM

Hey team

, I am having issues with DO

Error: Durable Object is overloaded. Requests queued for too long.

Error: Durable Object is overloaded. Requests queued for too long.

Error: Durable Object is overloaded. Requests queued for too long.

Error: Durable Object is overloaded. Requests queued for too long. .The document says

An individual Object has a soft limit of 1,000 requests per second.

An individual Object has a soft limit of 1,000 requests per second.

An individual Object has a soft limit of 1,000 requests per second.

An individual Object has a soft limit of 1,000 requests per second. is there a setting or configuration which can be set to increase this limit?

ᴀᴀkqj Hey team 👋 , I am having issues with DO `Error: Durable Object is overloaded. ...

I

Isaac McFadyen•2/7/25, 10:24 PM

No, it's a limitation of the Durable Object infrastructure and is only ever increased on internal Cloudflare applications if extremely needed. The recommended fix is to just use more than 1 Durable Object (which is the use-case DOs are designed for really)

I

Isaac McFadyen•2/7/25, 10:25 PM

The reason it's "soft" is that it'll heavily depend on how much computation you're doing in a single DO.

A

Avi•2/7/25, 11:42 PM

is there really no way to catch errors like this in cloudflare?

setTimeout(() => throw new Error("test"), 1000);

setTimeout(() => throw new Error("test"), 1000);

setTimeout(() => throw new Error("test"), 1000);

setTimeout(() => throw new Error("test"), 1000);

AAvi is there really no way to catch errors like this in cloudflare? ```js setTimeou...

I

Isaac McFadyen•2/7/25, 11:53 PM

Depends what you want to do with the catch. If you put a try-catch within the timeout itself it'll catch it but because it's in a timeout you can't reply to the client at that point.

IIsaac McFadyen Depends what you want to *do* with the catch. If you put a try-catch within the ...

A

Avi•2/8/25, 2:05 AM

I mean catching via some sort of global handler, like node has

uncaughtException

uncaughtException

uncaughtException

uncaughtException

A

Avi•2/8/25, 2:06 AM

if this happens in the codebase and someone forget to explicitly try-catch it, there is afaik zero way to observe or react to that

A

Avi•2/8/25, 2:06 AM

especially since it might not be in the context of a request as in a DO

AAvi if this happens in the codebase and someone forget to explicitly try-catch it, t...

I

Isaac McFadyen•2/8/25, 2:06 AM

You can use a Tail Worker: https://developers.cloudflare.com/workers/observability/logs/tail-workers/

I

Isaac McFadyen•2/8/25, 2:07 AM

A Tail Worker receives information about the execution of other Workers (known as producer Workers), such as HTTP statuses, data passed to console.log() or uncaught exceptions

I

Isaac McFadyen•2/8/25, 2:07 AM

I believe you can actually have it be the same worker

I

Isaac McFadyen•2/8/25, 2:07 AM

Just add a

tail

tail

tail

tail handler and in the wrangler.json/wrangler.toml, point the Worker to itself.

IIsaac McFadyen You can use a Tail Worker: https://developers.cloudflare.com/workers/observabili...

A

Avi•2/8/25, 2:08 AM

its a very poor solution for DOs, because tail worker only process on requests, and the HTTP req/response lifecycle often does not map cleanly onto DOs (that's the whole point of DOs!)

I

Isaac McFadyen•2/8/25, 2:08 AM

Ah I see

I

Isaac McFadyen•2/8/25, 2:08 AM

Not sure then.

A

Avi•2/8/25, 2:09 AM

seems like the "right" solutions would be for CF to either:
- implement

addEventListener('uncaughtexception', ...)

addEventListener('uncaughtexception', ...)

addEventListener('uncaughtexception', ...)

addEventListener('uncaughtexception', ...) like node does
or
- enable tailworkers to operate more granularly on the stream of events from a worker (e.g. console.log events in real time)

R

Rahul gangotri•2/8/25, 2:57 PM

Hi

Actually i was building a websocket product on durable objects for a pub sub based models

With channels like public, private, presence, cache

I create user apps where each user can create multiple apps and each app is a separate DO

I just want to have a quick chat with you to know that can i make this a saas model with just having 1 namespace and sell to users?

Is that technically possible? I know storage with be a limit, but i just need to store channel and its connected clients and not the messages

R

Rahul gangotri•2/8/25, 6:22 PM

anyone? From cloudflare?

Please reply

IiLearn Any thing similar to D1 "Export an existing D1 database" (https://developers.cl...

I

iLearnOP•2/8/25, 6:40 PM

bumping on top for response

D

DanTheGoodman•2/8/25, 10:14 PM

What's the current best way to handle shipping logs from durable objects to a custom destination? Specifically I'd like to just use a custom logger i have and ship the logs after responding to an RPC without holding the response to the invoking worker (plz ping me)

D

DanTheGoodman•2/8/25, 10:14 PM

Maybe tail workers? I'm not sure if they respond to RPCs to DOs as an exclusive event

RRahul gangotri anyone? From cloudflare? Please reply

1

1984 Ford Laser•2/8/25, 10:33 PM

Cloudflare employees aren't here to validate your business solutions for free, this is a community effort.

Hhannes nothing official, though I'm sure somewhere on Github someone wrote utility func...

I

iLearnOP•2/8/25, 11:32 PM

Thanks for pointers. Something better than Nothing

DDanTheGoodman What's the current best way to handle shipping logs from durable objects to a cu...

P

pandalambda2•2/9/25, 12:23 AM

Interesting in patterns around this as well. I want to ship to axiom.co. Shame they acquired and broke Baselime (just flat out doesn't work), but their analytics engine I think is the replacement, and similarly based on clickhouse, I'd be curious if that became the central sink and from there you could have forwarders push, or pull somehow

Ppandalambda2 Interesting in patterns around this as well. I want to ship to axiom.co. Shame t...

J

James•2/9/25, 1:53 AM

I flush logs to axiom at the end of each request. Since the DO persists until it’s done processing regardless of inbound RPC calls, just run the flush async without the await.

P

pandalambda2•2/9/25, 4:49 AM

I really would love to lift this out of app code though, it seems like a proper hack

Llambrospetrou First of all `await setAnotherAlarm()` does not set a new alarm, it overrides th...

P

peachneo•2/9/25, 6:46 AM

Hey Lambros, was wondering if the team got back to you on this

Regarding the behavior of setting an alarm and throwing right after, I will check with the team and get back to you.

Providing a more fleshed out example to better-communicate what I'm asking - hopefully it makes sense

export class MyDurableObject {
    constructor(state, env) {
        this.state = state;
        this.env = env;
    }

    async alarm() {
        console.log("Alarm triggered");

        // Will this alarm be set? or would it be "overriden" by the retry of the original alarm
        await this.state.storage.setAlarm(Date.now() + 150000);

        // Call a method that fails
        await this.failingMethod(); // failure
    }

    async fetch(request) {
        const url = new URL(request.url);

        if (url.pathname === "/start") {
            console.log("Starting recursive alarm loop...");
            await this.state.storage.setAlarm(Date.now() + 5000);
            return new Response("Alarm scheduled.");
        }

        return new Response("Unknown command", { status: 400 });
    }

    async failingMethod() {
        throw new Error("Intentional failure to demonstrate failure handling");
    }
}

export class MyDurableObject {
    constructor(state, env) {
        this.state = state;
        this.env = env;
    }

    async alarm() {
        console.log("Alarm triggered");

        // Will this alarm be set? or would it be "overriden" by the retry of the original alarm
        await this.state.storage.setAlarm(Date.now() + 150000);

        // Call a method that fails
        await this.failingMethod(); // failure
    }

    async fetch(request) {
        const url = new URL(request.url);

        if (url.pathname === "/start") {
            console.log("Starting recursive alarm loop...");
            await this.state.storage.setAlarm(Date.now() + 5000);
            return new Response("Alarm scheduled.");
        }

        return new Response("Unknown command", { status: 400 });
    }

    async failingMethod() {
        throw new Error("Intentional failure to demonstrate failure handling");
    }
}

export class MyDurableObject {
    constructor(state, env) {
        this.state = state;
        this.env = env;
    }

    async alarm() {
        console.log("Alarm triggered");

        // Will this alarm be set? or would it be "overriden" by the retry of the original alarm
        await this.state.storage.setAlarm(Date.now() + 150000);

        // Call a method that fails
        await this.failingMethod(); // failure
    }

    async fetch(request) {
        const url = new URL(request.url);

        if (url.pathname === "/start") {
            console.log("Starting recursive alarm loop...");
            await this.state.storage.setAlarm(Date.now() + 5000);
            return new Response("Alarm scheduled.");
        }

        return new Response("Unknown command", { status: 400 });
    }

    async failingMethod() {
        throw new Error("Intentional failure to demonstrate failure handling");
    }
}

export class MyDurableObject {
    constructor(state, env) {
        this.state = state;
        this.env = env;
    }

    async alarm() {
        console.log("Alarm triggered");

        // Will this alarm be set? or would it be "overriden" by the retry of the original alarm
        await this.state.storage.setAlarm(Date.now() + 150000);

        // Call a method that fails
        await this.failingMethod(); // failure
    }

    async fetch(request) {
        const url = new URL(request.url);

        if (url.pathname === "/start") {
            console.log("Starting recursive alarm loop...");
            await this.state.storage.setAlarm(Date.now() + 5000);
            return new Response("Alarm scheduled.");
        }

        return new Response("Unknown command", { status: 400 });
    }

    async failingMethod() {
        throw new Error("Intentional failure to demonstrate failure handling");
    }
}

Ppeachneo Hey Lambros, was wondering if the team got back to you on this > Regarding the ...

S

sathoro•2/9/25, 9:00 AM

just try it?

Original message was deleted

S

sathoro•2/9/25, 9:05 AM

other storage operations don't get rolled back. and I assume the alarm doesn't get "rolled back", but rather the exception overwrites the alarm when the retry logic is kicked in (which will trigger the alarm 2 seconds later)

S

sathoro•2/9/25, 9:06 AM

my assumption (I could be completely wrong here), is that it would be virtually identical to if you wrapped the alarm in a try..catch and then manually called setAlarm for 2 seconds later in the catch. that would "overwrite" any previous setAlarm call (minus the specific retry logic cf does)

S

sathoro•2/9/25, 9:08 AM

we do lots of background processing and queues with DOs and we almost always wrap the whole alarm handler in a try..catch and do custom retry logic. the default retry logic is not ideal in almost any real-world scenario

S

sathoro•2/9/25, 9:12 AM

one example for a multi-step queue, obviously use case dependent

try {
  //
} catch (error) {
  console.error(
    "x QUEUE ERROR",
    `Error processing step ${currentStep} for ${x}:`,
    error
  );

  sentry.captureException(error);

  const currentRetries = this.stepRetries[currentStep] || 0;
  const retryDelays = [
    1 * 60 * 1000, // 1 minute
    10 * 60 * 1000, // 10 minutes
    60 * 60 * 1000, // 1 hour
    4 * 60 * 60 * 1000, // 4 hours
    24 * 60 * 60 * 1000, // 24 hours
  ];

  if (currentRetries < retryDelays.length) {
    this.stepRetries[currentStep] = currentRetries + 1;
    const delay = retryDelays[currentRetries];
    this.setAlarm(Date.now() + delay);
    console.log(
      `Retrying step ${currentStep} (attempt #${
        this.stepRetries[currentStep]
      }) for ${x} in ${delay / 1000 / 60} minutes`
    );
  } else {
    console.error(
      "x SKIPPING STEP",
      `Step ${currentStep} failed ${retryDelays.length} times, skipping and moving to next step`
    );

    this.stepRetries[currentStep] = 0;
    this.step = currentStep + 1;
    this.setAlarm(Date.now());
  }

  await this.persist();
}

try {
  //
} catch (error) {
  console.error(
    "x QUEUE ERROR",
    `Error processing step ${currentStep} for ${x}:`,
    error
  );

  sentry.captureException(error);

  const currentRetries = this.stepRetries[currentStep] || 0;
  const retryDelays = [
    1 * 60 * 1000, // 1 minute
    10 * 60 * 1000, // 10 minutes
    60 * 60 * 1000, // 1 hour
    4 * 60 * 60 * 1000, // 4 hours
    24 * 60 * 60 * 1000, // 24 hours
  ];

  if (currentRetries < retryDelays.length) {
    this.stepRetries[currentStep] = currentRetries + 1;
    const delay = retryDelays[currentRetries];
    this.setAlarm(Date.now() + delay);
    console.log(
      `Retrying step ${currentStep} (attempt #${
        this.stepRetries[currentStep]
      }) for ${x} in ${delay / 1000 / 60} minutes`
    );
  } else {
    console.error(
      "x SKIPPING STEP",
      `Step ${currentStep} failed ${retryDelays.length} times, skipping and moving to next step`
    );

    this.stepRetries[currentStep] = 0;
    this.step = currentStep + 1;
    this.setAlarm(Date.now());
  }

  await this.persist();
}

try {
  //
} catch (error) {
  console.error(
    "x QUEUE ERROR",
    `Error processing step ${currentStep} for ${x}:`,
    error
  );

  sentry.captureException(error);

  const currentRetries = this.stepRetries[currentStep] || 0;
  const retryDelays = [
    1 * 60 * 1000, // 1 minute
    10 * 60 * 1000, // 10 minutes
    60 * 60 * 1000, // 1 hour
    4 * 60 * 60 * 1000, // 4 hours
    24 * 60 * 60 * 1000, // 24 hours
  ];

  if (currentRetries < retryDelays.length) {
    this.stepRetries[currentStep] = currentRetries + 1;
    const delay = retryDelays[currentRetries];
    this.setAlarm(Date.now() + delay);
    console.log(
      `Retrying step ${currentStep} (attempt #${
        this.stepRetries[currentStep]
      }) for ${x} in ${delay / 1000 / 60} minutes`
    );
  } else {
    console.error(
      "x SKIPPING STEP",
      `Step ${currentStep} failed ${retryDelays.length} times, skipping and moving to next step`
    );

    this.stepRetries[currentStep] = 0;
    this.step = currentStep + 1;
    this.setAlarm(Date.now());
  }

  await this.persist();
}

try {
  //
} catch (error) {
  console.error(
    "x QUEUE ERROR",
    `Error processing step ${currentStep} for ${x}:`,
    error
  );

  sentry.captureException(error);

  const currentRetries = this.stepRetries[currentStep] || 0;
  const retryDelays = [
    1 * 60 * 1000, // 1 minute
    10 * 60 * 1000, // 10 minutes
    60 * 60 * 1000, // 1 hour
    4 * 60 * 60 * 1000, // 4 hours
    24 * 60 * 60 * 1000, // 24 hours
  ];

  if (currentRetries < retryDelays.length) {
    this.stepRetries[currentStep] = currentRetries + 1;
    const delay = retryDelays[currentRetries];
    this.setAlarm(Date.now() + delay);
    console.log(
      `Retrying step ${currentStep} (attempt #${
        this.stepRetries[currentStep]
      }) for ${x} in ${delay / 1000 / 60} minutes`
    );
  } else {
    console.error(
      "x SKIPPING STEP",
      `Step ${currentStep} failed ${retryDelays.length} times, skipping and moving to next step`
    );

    this.stepRetries[currentStep] = 0;
    this.step = currentStep + 1;
    this.setAlarm(Date.now());
  }

  await this.persist();
}

Ppeachneo Hey Lambros, was wondering if the team got back to you on this > Regarding the ...

L

lambrospetrou•2/9/25, 1:41 PM

I did get back to you though

durable-objects

V

veeque•2/9/25, 5:18 PM

is it bad if i make a DO and then just "forget" about it? is there a way to tell cf "likely won't be using this, you can erase it"

Vveeque is it bad if i make a DO and then just "forget" about it? is there a way to tell...

I

Isaac McFadyen•2/9/25, 5:23 PM

The DO will remain as long as it has storage attached (it may go idle but the storage will persist). If you don't need the DO any more you can do a deleteAll() on the storage and then once idle the DO will be terminated.

V

veeque•2/9/25, 5:29 PM

i'll assume that to also be what i should do instead of littering with random DOs

Vveeque i'll assume that to also be what i should do instead of littering with random DO...

B

boop•2/9/25, 5:30 PM

As long as you don't store anything to persistent storage, you don't have to worry about it - the DO will just cease to exist

Vveeque is it bad if i make a DO and then just "forget" about it? is there a way to tell...

L

lambrospetrou•2/9/25, 5:45 PM

The approach I like to think about Durable Objects, and suggest others too, is to stop worrying about "managing the Durable Objects themselves".
When you need them, you just reference them, and they will magically appear. You don't ever delete DOs. By deleting their storage you just stop paying for storage. Even after

deleteAll()

deleteAll()

deleteAll()

deleteAll(), you can reference the same ID and get it running again.

Obviously, without any storage used a DO is stateless so its ID doesn't matter much other than for a few seconds before it hibernates again, but it doesn't change the fact that you should not think in terms of creating and deleting DOs.
You delete the storage to not pay for it, not to delete the DO. That's just an implementation detail.

This is also what some literature refers to as "virtual actors", they always exist and are always addressable.

Llambrospetrou The approach I like to think about Durable Objects, and suggest others too, is t...

H

Hello, I’m Allie!•2/9/25, 6:33 PM

I’m wondering though, for cases where you store a little bit of data but then forget to clean it up, or do have machinery to clean up that just happened not to work in that case, what should you do? A few bytes here and there won’t do much, but it could become a problem at some point, depending on scale.

One fix is always to nuke the entire namespace, but that sucks if you have data you do want to keep

HHello, I’m Allie!I’m wondering though, for cases where you store a little bit of data but then fo...

L

lambrospetrou•2/10/25, 12:28 AM

What does "forget" mean though? I cannot give an answer as generic as that. If a resource has been deleted from the rest of your application and not the DO storage, then you should have a trail of the deletion somewhere in the system, and maybe even do a crawl after the fact to clean up or something.

K

kchro3•2/10/25, 1:03 AM

I have a usability question with Durable Objects. We have a CICD pipeline where we stage our branches to a stage env, but because of how DOs do migrations, if one person adds a DO in a PR, everyone else’s PR start failing to deploy because it’s missing a delete tag for a Durable Object that doesn’t exist yet.

Is there a recommended way to do CICD here?

11984 Ford Laser Do SQL triggers work in DOs? I swear someone posted that they'd gotten it workin...

1

1984 Ford Laser•2/10/25, 7:28 AM

Anyone have any ideas on this one?

D

DiamondDragon•2/10/25, 8:18 AM

can someone help me here? I have this general basic setup and am trying to do R2 operations within a DO but , but i cannot figure out why the env bindings are not being recognized . I get

[ERROR] TypeError: Cannot read properties of undefined (reading 'MY_BUCKET')

[ERROR] TypeError: Cannot read properties of undefined (reading 'MY_BUCKET')

[ERROR] TypeError: Cannot read properties of undefined (reading 'MY_BUCKET')

[ERROR] TypeError: Cannot read properties of undefined (reading 'MY_BUCKET'). I can do R2 operations in the hono routes but not within the DO at the moment using the bindings

The use case is i need to upload a large CSV file so need to use R2 storage rather than DO storage

I am running this local.

type Bindings = {
    MY_BUCKET: R2Bucket
    MY_DO: DurableObjectNamespace<MyDurableObject>
}

type Variables = {}

export type Env = {
    Bindings: Bindings
    Variables: Variables
}

type Bindings = {
    MY_BUCKET: R2Bucket
    MY_DO: DurableObjectNamespace<MyDurableObject>
}

type Variables = {}

export type Env = {
    Bindings: Bindings
    Variables: Variables
}

type Bindings = {
    MY_BUCKET: R2Bucket
    MY_DO: DurableObjectNamespace<MyDurableObject>
}

type Variables = {}

export type Env = {
    Bindings: Bindings
    Variables: Variables
}

type Bindings = {
    MY_BUCKET: R2Bucket
    MY_DO: DurableObjectNamespace<MyDurableObject>
}

type Variables = {}

export type Env = {
    Bindings: Bindings
    Variables: Variables
}

Durable Object Definition

export class MyDurableObject extends DurableObject<Env> {
    storage: DurableObjectStorage

    constructor(ctx: DurableObjectState, env: Env) {
        super(ctx, env)
        this.storage = ctx.storage
        console.log('DO constructor', this.env)
    }

    async test() {
        const upload = await this.env.Bindings.MY_BUCKET.put(`test`, 'test')
        return upload
    }
}

export class MyDurableObject extends DurableObject<Env> {
    storage: DurableObjectStorage

    constructor(ctx: DurableObjectState, env: Env) {
        super(ctx, env)
        this.storage = ctx.storage
        console.log('DO constructor', this.env)
    }

    async test() {
        const upload = await this.env.Bindings.MY_BUCKET.put(`test`, 'test')
        return upload
    }
}

export class MyDurableObject extends DurableObject<Env> {
    storage: DurableObjectStorage

    constructor(ctx: DurableObjectState, env: Env) {
        super(ctx, env)
        this.storage = ctx.storage
        console.log('DO constructor', this.env)
    }

    async test() {
        const upload = await this.env.Bindings.MY_BUCKET.put(`test`, 'test')
        return upload
    }
}

export class MyDurableObject extends DurableObject<Env> {
    storage: DurableObjectStorage

    constructor(ctx: DurableObjectState, env: Env) {
        super(ctx, env)
        this.storage = ctx.storage
        console.log('DO constructor', this.env)
    }

    async test() {
        const upload = await this.env.Bindings.MY_BUCKET.put(`test`, 'test')
        return upload
    }
}

Calling the Durable Object in Hono

// do imported above

const id = c.env.MY_DO.idFromName('my-durable-object')
const durableObject = c.env.MY_DO.get(id)
const zipFile = await durableObject.test()
return c.json({ message: 'Test', zipFile })


export {MY_DO}

// do imported above

const id = c.env.MY_DO.idFromName('my-durable-object')
const durableObject = c.env.MY_DO.get(id)
const zipFile = await durableObject.test()
return c.json({ message: 'Test', zipFile })


export {MY_DO}

// do imported above

const id = c.env.MY_DO.idFromName('my-durable-object')
const durableObject = c.env.MY_DO.get(id)
const zipFile = await durableObject.test()
return c.json({ message: 'Test', zipFile })


export {MY_DO}

// do imported above

const id = c.env.MY_DO.idFromName('my-durable-object')
const durableObject = c.env.MY_DO.get(id)
const zipFile = await durableObject.test()
return c.json({ message: 'Test', zipFile })


export {MY_DO}

Logging and Error Output

DO constructor {
    MY_DO: DurableObjectNamespace {},
    MY_BUCKET: R2Bucket {},

  }
  ✘ [ERROR] TypeError: Cannot read properties of undefined (reading 'MY_BUCKET')

DO constructor {
    MY_DO: DurableObjectNamespace {},
    MY_BUCKET: R2Bucket {},

  }
  ✘ [ERROR] TypeError: Cannot read properties of undefined (reading 'MY_BUCKET')

DO constructor {
    MY_DO: DurableObjectNamespace {},
    MY_BUCKET: R2Bucket {},

  }
  ✘ [ERROR] TypeError: Cannot read properties of undefined (reading 'MY_BUCKET')

DO constructor {
    MY_DO: DurableObjectNamespace {},
    MY_BUCKET: R2Bucket {},

  }
  ✘ [ERROR] TypeError: Cannot read properties of undefined (reading 'MY_BUCKET')

DDiamondDragon can someone help me here? I have this general basic setup and am trying to do R2...

L

lambrospetrou•2/10/25, 9:30 AM

Speculating here since I didn't run your code, but the

env

env

env

env you get in the DO constructor has nothing to do with the Hono env. In your code it should be the

Bindings

Bindings

Bindings

Bindings directly. So doing

await this.env.MY_BUCKET.put(...)

await this.env.MY_BUCKET.put(...)

await this.env.MY_BUCKET.put(...)

await this.env.MY_BUCKET.put(...) will probably work.
And your logging BTW confirms this.
DOs constructor receive the Worker's definition of Env, as defined in your wrangler configuration.

Kkchro3 I have a usability question with Durable Objects. We have a CICD pipeline where ...

L

lambrospetrou•2/10/25, 9:33 AM

If you want folks to be able to add/remove DOs on their own without impacting the rest, then each PR or person should get their own worker projects so they will be different DO namespaces. This of course means someone's worker won't communicate with someone else's.

Llambrospetrou What does "forget" mean though? I cannot give an answer as generic as that. If a...

H

Hard@Work•2/10/25, 11:35 AM

Like, I have a few apps that are reasonably simple, a few lines of DO code, and a few i/o calls. While I know now to be more thorough, and ensure that the DOs clean themselves up, I didn't always, nor do I think that people who are starting fresh on the platform would know to do so

H

Hard@Work•2/10/25, 11:37 AM

While for production apps, there should always be a cleanup mechanism, I do think that it might be unreasonable to expect first-time Cloudflare/DevPlatform users to know they need a full DO ops logging system/AutoCleanup tool right off the bat. The "Delete the entire namespace" escape hatch is still there as a cleanup function, but it seems a tad heavyhanded

HHard@Work Like, I have a few apps that are reasonably simple, a few lines of DO code, and ...

L

lambrospetrou•2/10/25, 12:00 PM

I still don't follow the use-case. You have say 1000 DOs with storage used for actual data. But, now you deleted the entities related to those DOs from a different part of your applications but forgot about the DOs, and you are wondering how to delete those 1000 DOs?

To phrase it differently, what do you need the DOs to do in this example you have in mind?

Any thing similar to D1 "Export an existing D1 database" (https://developers.cloudflare.com/d1/best

Similar Threads