James M Snell

> ... We could bikeshed the API, I suppose, as the new limits config field is sort of a tiny DSL. Yeah, I didn't bother putting a ton of effort...

I've added the requirement that this can only be used when using `--experimental` and put clear indications in the comments in the capnp that it is experimental and subject to...

Interesting, ok, just so I understand... rather than crashing the process when we hit the hard limit, we'd effectively terminate the worker and just start returning 500s? Like in production,...

Putting this back into draft status while I work on @mrbbot's feedback

> ... do we have a timeline to when this might be fixed? No specific timeline yet but I'll raise this again in internal discussions to see if we can...

Changing the label on this to `feature-request` from `bug`. Will be upping the priority on getting this implemented.

We'll need a simple reproduction example in order to diagnose this.

Which workers syntax are y'all using? The older "server worker" syntax (using `addEventListener`) or the new ESM syntax e.g. `export default { async fetch .... }` ? If you have...

@irvinebroque ... the `require(...)` method is not present in regular ESM modules so I wouldn't expect that to work. The `require(...)` method is only injected into common js and node.js...

I'm going to remove the `bug` label from this issue as this really isn't a bug in the runtime as much as it is just a limitation of the current...