I get some strange leakage between tests... I have a test that succeeds if other tests are commente

I get some strange leakage between tests...

I have a test that succeeds if other tests are commented out, or if it's anywhere but the first test to run. It will also succeed on live reload.

It fails because

const ran = await runDurableObjectAlarm(stub); expect(ran).toBe(true);

const ran = await runDurableObjectAlarm(stub); expect(ran).toBe(true);

// expects true but is false

    it("adds jobs and schedules an alarm", async () => {
      const result = await runInDurableObject(stub, async (instance, state) => {
        return await instance.addJobs([
          { url: "https://example.com" },
          { url: "https://example.org" },
        ]);
      });
      expect(result).toBe("Jobs added");

      // Run the alarm (which calls processQueue & processTimeouts)
      const ran = await runDurableObjectAlarm(stub);
      expect(ran).toBe(true);

      const status = await runInDurableObject(stub, async (instance) => {
        return await instance.getStatus();
      });
      expect(status).toEqual([{ status: "pending", count: 2 }]);
    });

    it("adds jobs and schedules an alarm", async () => {
      const result = await runInDurableObject(stub, async (instance, state) => {
        return await instance.addJobs([
          { url: "https://example.com" },
          { url: "https://example.org" },
        ]);
      });
      expect(result).toBe("Jobs added");

      // Run the alarm (which calls processQueue & processTimeouts)
      const ran = await runDurableObjectAlarm(stub);
      expect(ran).toBe(true);

      const status = await runInDurableObject(stub, async (instance) => {
        return await instance.getStatus();
      });
      expect(status).toEqual([{ status: "pending", count: 2 }]);
    });

    it("adds jobs and schedules an alarm", async () => {
      const result = await runInDurableObject(stub, async (instance, state) => {
        return await instance.addJobs([
          { url: "https://example.com" },
          { url: "https://example.org" },
        ]);
      });
      expect(result).toBe("Jobs added");

      // Run the alarm (which calls processQueue & processTimeouts)
      const ran = await runDurableObjectAlarm(stub);
      expect(ran).toBe(true);

      const status = await runInDurableObject(stub, async (instance) => {
        return await instance.getStatus();
      });
      expect(status).toEqual([{ status: "pending", count: 2 }]);
    });

    it("adds jobs and schedules an alarm", async () => {
      const result = await runInDurableObject(stub, async (instance, state) => {
        return await instance.addJobs([
          { url: "https://example.com" },
          { url: "https://example.org" },
        ]);
      });
      expect(result).toBe("Jobs added");

      // Run the alarm (which calls processQueue & processTimeouts)
      const ran = await runDurableObjectAlarm(stub);
      expect(ran).toBe(true);

      const status = await runInDurableObject(stub, async (instance) => {
        return await instance.getStatus();
      });
      expect(status).toEqual([{ status: "pending", count: 2 }]);
    });

The add jobs instance call simply inserts some records and sets an alarm

peachneoOP•2/15/25, 1:38 AM

I know there's this in the docs

Durable Object alarms are not reset between test runs and do not respect isolated storage. Ensure you delete or run all alarms with runDurableObjectAlarm() scheduled in each test before finishing the test.

Durable Object alarms are not reset between test runs and do not respect isolated storage. Ensure you delete or run all alarms with runDurableObjectAlarm() scheduled in each test before finishing the test.

But I believe my afterEach should cover this

  afterEach(async () => {
    // Clear any pending alarms between tests.
    await runInDurableObject(stub, async (_instance, state) => {
      await state.storage.deleteAlarm();
    });
    vi.restoreAllMocks();
  });

  afterEach(async () => {
    // Clear any pending alarms between tests.
    await runInDurableObject(stub, async (_instance, state) => {
      await state.storage.deleteAlarm();
    });
    vi.restoreAllMocks();
  });

1984 Ford Laser•2/15/25, 8:42 AM

If I have a Worker that iterates over a list of strings, gets a stub for each string, then calls

this.state.getWebSockets

this.state.getWebSockets

on each stub, is this 1 DO request per stub? Do these count toward the subrequest limit of the initially invoked Worker?

sneakyf1shy•2/15/25, 3:38 PM

is there a proper way to use durable objects inside NextJS on cloudflare pages?

sneakyf1shy•2/15/25, 3:38 PM

I can't seem to find anything new online, only like a github issue closed in 2023

Ppeachneo I get some strange leakage between tests... I have a test that succeeds if othe...

Fernando Barroso•2/15/25, 5:13 PM

I had something similar happen to me and the way I was able to fix it was by trying different combinations of isolated storage and single worker configs that made sense for my type of tests:

https://developers.cloudflare.com/workers/testing/vitest-integration/isolation-and-concurrency/

I also found that I was placing these params on the wrong object in my vitest config file so these params weren’t working until I fixed that (which took me freaking days to figure out it was so frustrating

Cloudflare Docs

Isolation and concurrency · Cloudflare Workers docs

Review how the Workers Vitest integration runs your tests, how it isolates tests from each other, and how it imports modules.

Ppeachneo I know there's this in the docs ``` Durable Object alarms are not reset between...

Fernando Barroso•2/15/25, 5:14 PM

Also you may want to just run the alarm in your afterEach instead of deleting using runInDurableObject

Fernando Barroso•2/15/25, 5:14 PM

That also helped me

iLearn•2/16/25, 10:12 AM

DO-Compute Billing Time Vs Workers Compute Billing Time

AIM : To understand DO Compute billing.
(PLEASE NOTE : i am aware that DO billing is based on Wall Clock time while Workers billing is based on CPU time)

Simple Use-case : Make an entry in Workers-KV (key : "hello", value "world" )

IF, Workers consumes 10ms (and hence billing time = 10ms) for above simple Use-case, is it "FAIRLY ACCURATE" to assume that the DO will also consume 10ms (and hence billing time = 10ms) for the same Use-case.

Will the DO billing charge for cold-starts etc ?

IiLearn **DO-Compute Billing Time Vs Workers Compute Billing Time** AIM : To understand...

lambrospetrou•2/16/25, 10:48 AM

Will the DO billing charge for cold-starts etc ?

No, you pay only the time after your DO is running.

IF, Workers consumes 10ms (and hence billing time = 10ms) for above simple Use-case, is it "FAIRLY ACCURATE" to assume that the DO will also consume 10ms (and hence billing time = 10ms) for the same Use-case.

Assuming that the

10ms

10ms

is actual round trip time for your operation, then yes, DOs should have similar performance as Workers. It's the same runtime so code behavior is identical.

One note, a DO is in a single location though, whereas a Worker can be anywhere or even smart placed. So, latencies might be different from Workers just because of where your DO will be located.

Llambrospetrou > Will the DO billing charge for cold-starts etc ? No, you pay only the time aft...

sneakyf1shy•2/16/25, 2:53 PM

heya - is there any docs or example/way to use

@cloudflare/next-on-pages

@cloudflare/next-on-pages

with DO's?

Llambrospetrou > Will the DO billing charge for cold-starts etc ? No, you pay only the time aft...

iLearn•2/16/25, 5:02 PM

Thanks for crisp answer.

lambrospetrou•2/16/25, 5:26 PM

Hey folks, I just released

durable-utils@0.3.0

durable-utils@0.3.0

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

The main update is the

StaticShardedDO

StaticShardedDO

abstraction extended with more methods

one/some/all()

one/some/all()

and

tryOne/trySome/tryAll()

tryOne/trySome/tryAll()

. There are a couple other utilities added for retries like

tryN(...)

tryN(...)

.

If anyone is sharding their DOs, try out the

StaticShardedDO

StaticShardedDO

class and let me know what you think or what's not convenient.

Read the docs first to avoid any data loss. This is "static number of shards". You cannot change them after creation.

GitHub

GitHub - lambrospetrou/durable-utils: Utilities for Cloudflare Dura...

Utilities for Cloudflare Durable Objects and Workers - lambrospetrou/durable-utils

iLearn•2/16/25, 5:41 PM

DO-Compute Cost Vs Workers Compute Cost
(Adding Update to avoid any confusion :
Assumption : Both, DO and Workers are NOT performing any IO operations)

Since, both costing are based on different metric, so done a simple back-of-the paper mathematics to have common metric to compare.

Worker Compute Pricing (after FREE Tier) : $0.02 per million CPU milliseconds
= (0.02 ) / (1,000,000 * 128MB * 0.001s) = (0.02) / (1000 * 128 MB-s) = (0.02) / (128 GB-s)
= $ 0.00015625 per GB-second

DO Compute Pricing (after FREE Tier) : $12.50/million GB-s = $ 0.0000125 per GB-second

Conclusion : Workers Compute is 12.5x times COSTLIER than DO-Compute. (Subject to the Assumption stated above)
(Though, funny part is DO necessarily requires a parent Worker for itself to be invoked, so using DO necessarily requires 2 compute - Parent Worker Compute + DO Compute)

Please confirm /update above calculation and understanding.

Llambrospetrou Hey folks, I just released `durable-utils@0.3.0`: https://github.com/lambrospetr...

iLearn•2/16/25, 6:03 PM

Can you please share a simple practical use-case for using "StaticShardedDO" ?
Thanks.

IiLearn **DO-Compute Cost Vs Workers Compute Cost** (Adding Update to avoid any confusio...

lambrospetrou•2/16/25, 6:16 PM

The dimensions are very different. CPU seconds vs WALL-TIME seconds. DOs also charge for requests and storage.
You cannot make general statements about pricing. In most real world scenarios Workers are cheaper than DOs since most applications have a lot of IO, hence wall-time is orders of magnitude more than CPU time.

Take your usecase, and then put the numbers based on actual data.

Llambrospetrou The dimensions are very different. CPU seconds vs WALL-TIME seconds. DOs also c...

iLearn•2/16/25, 6:20 PM

My calculations are apple-to-apple comparsion for Compute cost calculation and NOT for any use-case specific.

For specific use-case, ofcourse a new set of calculations need to be done. and your points are well-taken.

IiLearn My calculations are apple-to-apple comparsion for Compute cost calculation and N...

lambrospetrou•2/16/25, 6:22 PM

Conclusion : Workers Compute is 12.5x times COSTLIER than DO-Compute.

That's a very unusual conclusion for real world applications. Anyone can do their calculations of course, but please be careful when you compare them otherwise you will be in for not so nice surprises.

Llambrospetrou > Conclusion : Workers Compute is 12.5x times COSTLIER than DO-Compute. That's a...

iLearn•2/16/25, 6:25 PM

Agree.
I am just keeping all comparsions across various CF products and trying to make decisions on "same - metrics"

Original message was deleted

iLearn•2/16/25, 6:27 PM

really ? .. this is now making me scary, if such hidden calculations are used for billing ..
can you plz share this in any CF billing web-page .. thanks ..

Original message was deleted

lambrospetrou•2/16/25, 6:48 PM

DOs bill on wall time duration. That formula is definitely wrong as well, since

walltime

walltime

is the max of it anyway in the worst case.

Original message was deleted

Isaac McFadyen•2/16/25, 10:00 PM

That was a while back and it was Unbound Workers I believe

Isaac McFadyen•2/16/25, 10:00 PM

I recall the same docs line

Isaac McFadyen•2/16/25, 10:01 PM

It was kinda hidden too, "they will bill for a multiple of CPU time if it's greater" and that was it for docs

1984 Ford Laser•2/17/25, 12:21 AM

My understanding is that the main reason for the difference between charging for CPU time on Workers, and wall time on DOs, is that the main time sink with Workers is IO, DOs internal IO is very fast however. If most of the main compute is done in a worker invocation, then you pull a stub and write to the stubs storage, you're going to be looking at favourable wall times versus doing all of the calculation in the DO itself, especially if needing to pull from external APIs and such

1984 Ford Laser•2/17/25, 7:06 AM

Looking for thoughts on the following thought process I'm having with DOs:

I have a number of users who will open a browser or similar client. They will pull a DO stub for their own user_id, connect to Websockets and listen for notifications
An admin user posts a new message, which pulls a list of all subscribed user_id'ss and generates a stub for each user, pulls all open Websockets, and sends the message (a single user may have multiple clients listening for notifications at once)

What's the best way to handle this pattern In theory? Each message being sent could be going out to any number of users (in the 10s of thousands for reasonable scale assumptions), is there a way to use subrequests or similar to be able to instantiate many stubs and send a message to many users? I don't wanna spend too long going down a particular experiment to find there's an existing solution, or if there's an architectural reason why this pattern should not be used

iLearn•2/17/25, 5:52 PM

Is DO Compute Time also added to Parent Worker Compute Time ?

Simple Use-Case : Time_START--->Parent Worker receives HTTP Request ---> Parent Worker invokes a DO ---> DO takes 10ms for its own compute ---> DO returns ---> Parent Worker returns HTTP Response--->Time_END
Assume : Nothing is done by Worker, just receive HTTP request and return response from DO

Total Time "Consumed" (NOT, Billed) by Worker = Time_END - Time_START
Total Time "Consumed" by DO = 10ms

Q#1 : What is "billable compute" time for Worker ?
A#1 : (My Understanding) : Time_END - Time_START - 10ms

Q#2 : What is "billable compute" time for DO ?
A#2 : (My Understanding) : 10ms

Please confirm / update answer for Qs.

IiLearn Is DO Compute Time also added to Parent Worker Compute Time ? Simple Use-Case :...

John Spurlock•2/17/25, 6:39 PM

that's right, the parent worker is only charged for cpu cycles it uses within itself, which may include a bit of marshaling for the DO request/response, but not when purely waiting on IO from a DO or any other network call.

JJohn Spurlock that's right, the parent worker is only charged for cpu cycles it uses within it...

iLearn•2/17/25, 6:40 PM

Thanks for confirmation and explaination.

IiLearn Thanks for confirmation and explaination.

John Spurlock•2/17/25, 6:44 PM

np, you probably already know that DOs are charged differently than regular workers: by wall time, not cpu time. So if the DO in your example turned around and made another DO call or another network call, it will be charged for the entire time. So even though the code might look similar (or even be the same if you're using a shared library), the billing implications are different.

JJohn Spurlock np, you probably already know that DOs are charged differently than regular work...

iLearn•2/17/25, 6:48 PM

Thanks. I am aware of the wall time (for DO) vs cpu time (for Workers) based calculations.

IiLearn Is DO Compute Time also added to Parent Worker Compute Time ? Simple Use-Case :...

lambrospetrou•2/17/25, 6:49 PM

Q#1 : What is "billable compute" time for Worker ?
A#1 : (My Understanding) : Time_END - Time_START - 10ms

This is NOT correct. Since your worker was just waiting for the DO here it doesn't count as CPU time and shouldn't be billed.

Llambrospetrou > Q#1 : What is "billable compute" time for Worker ? > A#1 : (My Understanding) ...

John Spurlock•2/17/25, 6:49 PM

he's subtracting out the 10ms of waiting (is how I read this at least)

JJohn Spurlock he's subtracting out the 10ms of waiting (is how I read this at least)

lambrospetrou•2/17/25, 6:50 PM

Ah, in that case OK it's correct. I missed the subtraction for the 10ms and read it as equal.

Llambrospetrou Hey folks, I just released `durable-utils@0.3.0`: https://github.com/lambrospetr...

Fernando Barroso•2/17/25, 10:13 PM

This looks awesome. Question - do you think this could be used to horizontally scale storage for larger limits than 10GB? For example, I want to create an event store on durable objects, but the number of events will likely be > 10GB, so sharding sounds like a good idea.

However, I’m wondering if this would require custom logic if I want all events to be ordered across shards. This looks like it’s just hashing using the xxHash32 function which I think wouldn’t work for an ordering use case. Am I right? I’d prob have to add some ordering logic on top of that hashing function

FFernando Barroso This looks awesome. Question - do you think this could be used to horizontally s...

lambrospetrou•2/17/25, 11:00 PM

Yes, the goal of the sharding abstraction is to grow above the 10GB limit.
There are multiple approaches to handle ordering ontop of that. You could even have multiple levels of sharding, e.g. a tree of DO shards. The hash function needs to spread the load as much as possible to the shards.
The rest can be done ontop of that.

For example, a super simple approach is to bucket your events depending on your volume. Like buckets of 5 seconds. And then all events mapping to a 5s bucket are using the same partition key, so you have locality for those 5s to batch process all events of those seconds together. It depends on volume though of your application and specific needs.

Llambrospetrou Yes, the goal of the sharding abstraction is to grow above the 10GB limit. There...

Fernando Barroso•2/17/25, 11:36 PM

This is very interesting! Would you suggest using the StaticShardedDO as more of a “storage” layer and adding this global ordering type of logic on a class which extends this class?

Also, do you ever see a future possibility of making the # of shards dynamic? AKA scaling storage practically infinitely?

HowlOftheSun•2/18/25, 1:08 AM

is there a way to generate DO types so that workers that dont define the DO can take advantage of type hints in the ide?

HHowlOftheSun is there a way to generate DO types so that workers that dont define the DO can ...

hunt•2/18/25, 3:54 AM

do you mean if you're accessing the type through a binding? (i.e. worker A defines a DO that worker B is trying to access)

HowlOftheSun•2/18/25, 3:56 AM

Yep

hunt•2/18/25, 3:57 AM

I haven't seen a way to do that in a typegen fashion, but it can be solved by making a quick edit to the env object in the referencing worker

hunt•2/18/25, 3:57 AM

https://github.com/hntrl/durable-object-rpc-repro/blob/9804eccb6468db2d0363ca86aa1f1e96e63f7c63/packages/workerB/worker-configuration.d.ts#L4

hunt•2/18/25, 3:59 AM

(setting the type parameter of the Fetcher to whatever it is you're trying to access)

HowlOftheSun•2/18/25, 4:00 AM

Cool. It be interesting if the typegen could do it. I should probably just be more organized with my code

hunt•2/18/25, 4:12 AM

I actually made that repo for a different question I wanted to ask here: What's wrong with returning a durable object stub as an "rpc target" and accessing it in a different worker?

https://github.com/hntrl/durable-object-rpc-repro

my thinking would be that FooDurableObject would behave similarly to an RpcTarget where it can be returned from its parent worker, and I can access the methods on it from a service binding. If I try and do that though I get a message like

Could not serialize object of type "DurableObject"

Could not serialize object of type "DurableObject"

hunt•2/18/25, 4:13 AM

There's this section of the docs that would make me think this happens on its own: https://developers.cloudflare.com/workers/runtime-apis/rpc/#forwarding-rpc-stubs

Cloudflare Docs

Remote-procedure call (RPC) · Cloudflare Workers docs

The built-in, JavaScript-native RPC system built into Workers and Durable Objects.

Hhunt There's this section of the docs that would make me think this happens on its ow...

1984 Ford Laser•2/18/25, 4:30 AM

I believe that section on the docs is more general to Workers, and not specifically related to Durable Objects. An

RpcTarget

RpcTarget

class will need to proxy function calls to required stub. In your example,

BarRpcTarget

BarRpcTarget

needs to extend RpcTarget, and its constructor() should add the required stub which was already pulledby the instanced Worker, and also have class methods that will essentially call

this.stub.func()

this.stub.func()

on the actual DO stub. Screenshot is an example of my implementation for

RpcTarget

RpcTarget

hunt•2/18/25, 4:52 AM

Gotcha. Thats a neat workaround! It seems kind of awkward to have to redefine a separate rpc target interface that has the same prototype as the object, but if that’s how it has to be then I’ll live

I included the bit on the docs (partially to correct my understanding) bc from what I understand I’d think that a DO stub and an instance of an rpc target are pretty much one in the same in terms of how rpc is orchestrated, so between workers they should behave the same. I also included the BarRpcTarget just to illustrate that “if both are considered RPC stubs, why would they be treated differently?”

hunt•2/18/25, 5:04 AM

The key difference would be that DO stubs are rpc targets to a completely different compute layer (RpcTarget stays on the executing worker) which is why I thought forwarding stubs was relevant here

FFernando Barroso This is very interesting! Would you suggest using the StaticShardedDO as more of...

lambrospetrou•2/18/25, 8:37 AM

adding this global ordering type of logic on a class which extends this class

Not sure if extending is the right thing, I usually prefer composition, so another class using the sharding abstraction as its storage layer and for localized queries. The outer class is mostly to orchestrate which shards to query and do potential aggregations if needed.

do you ever see a future possibility of making the # of shards dynamic? AKA scaling storage practically infinitely?

Absolutely. It's in my plans, but I want to find a nice API for it first. Dynamic shards need splitting and merging shards over time, so ideally we should provide some DO native hooks for it. Until those are built and published I want to experiment doing it ontop but needs some time.

11984 Ford Laser I believe that section on the docs is more general to Workers, and not specifica...

lambrospetrou•2/18/25, 8:41 AM

One change I would do here if I understand your classes, is that the RpcTarget should be created from the DO side, not the caller Worker side otherwise it's tied to the Worker's lifecycle. If the DO returns an RpcTarget then method calls on the RpcTarget are going to be executed in the DO itself.

For example having a method getRpcTarget()getRpcTarget() on your DO, and calling it from a Worker allows you to pass around that returned value and anyone calling it will go back to the DO.

I get some strange leakage between tests... I have a test that succeeds if other tests are commente

Similar Threads