thats not true either; its just much easier to add 1 utility function to 3 years worth of framework/projects than it is to go thru the rabbitholes & add/update parameters for nearly every utility function

modules ftw, but grabbing

waitUntil

from X instead of from Y serves no benefit to me

But.. back to the AssetHandler, I think it would actually be a pretty good solution

cuz it addresses the same thing all/most other utilities are gunna face

aka, all my project code. thats why im gunna be doing it everywhere

So you would import the module version of KV and it would assemble the FetchEvent and call the "regular" handler?

module version of KV?

For your solution you would need to have a separate import if you want to run modules right?

I personally would prefer that the KV binding were always passed in. A separate export could avoid the need for new major version, but if major is on the table, then (event, option.binding) pair would work for both fairly easily. The breaking change would just be that option is a binding and not a string

Is there a way to get the ID of the durable object from within the object itself?

yep, you can get it from the

state

parameter passed to the constructor: https://developers.cloudflare.com/workers/runtime-apis/durable-objects#durable-object-class-definition

js
export class DurableObject {
  constructor(state, env){
    this.id = state.id;
  }

  async fetch(request) {
    return new Response(this.id.toString());
  }
}

ah, awesome thranks 🙂

Suppose we have a scenario that a user calls a worker, that worker than calls a DurableObject which wants to perform some long running operation. If the user reloads their tab before the long running operation has finished what will happen?

good question, not so sure 😕

Ye.. I kind of need a way to trigger an operation that might take some time such as sending an email or uploading a file somewhere for example. If that operation is cancelled because the user reloaded their tab thats not good

I assume it would just keep running. The Worker doesn't know they reloaded unless there was like a websocket.

Ah okay I thought I read somewhere that it terminates

I don't know for sure, you should probably test, I'm just assuming

Perhaps it terminates if the connection from the worker to the DO terminates?

anyone have a nice way to use the transactional storage API from the worker (rather than the DO)?

@Deleted User I don't think the worker has a transactional storage API. I have a Durable Object that acts as a REST API and an Client in the worker that acts like the storage API from the DO's, but the only thing that doesn't support yet is transactions.

er, right, bad wording

so the problem is i definitely need to somehow access the transactional api from the worker

of course, given that there is no transactional api on the stub itself, you'd probably need to serialize it somehow

i wonder if a custom HTTP method would be a bad idea...

Yeah that could be tricky, since you'd probably want to read and write within an transaction based on the read that you do.

ya

If it's an increment for an number for example, you can probably write something for that.

/increment?key=counter:ID&amount=43221

Than do the read + write in an transaction that increments that.

the problem, of course