unfortunately no, I did mean just bare TCP

Ah okay

websockets would be much easier 😅

Yeah inbound TCP isn't a thing yet, but something we'll likely see in future. No ETA I'm aware of.

Hey all, I've been running into an issue where a specific subset of requests to my worker are canceled.It only occurs on one code path, after all other conditions have been ruled out, which simply forwards users on to their original request with code similar to the following:

let resp = await fetch(request)
resp = new Response(resp.body, resp)
resp.headers.append("Set-Cookie", newCookie) // only if they have no cookie yet
return resp

Does anyone have ideas on how to debug this, or common things to look out for when requests get canceled? I have more details here in case more info is needed: https://discord.com/channels/595317990191398933/1109019842306134086/1109019842306134086,

do you know if anyone's been admitted to the private beta / etc? I've asked our account manager but figured the Discord might know quicker

I don't think it even exists yet, frankly

well that would definitely prevent anyone from being in the beta wouldn't it 😆

i was reading workerd code and couldn't find any references so i was kinda thinking that

I'm trying to import a node.js module that is scoped (using @, like

@subsquid/ss58-codec

), however wrangler build fails and intellisense is obviously complaining. Does the

node:

prefix for imports not work for scoped packages?

If it's a regular npm package, you shouldn't be using the

node:

prefix

that's for nodejs modules, like

path

, and

buffer

Oh I see, I'm misunderstanding this line from the docs: "this prefix must be used when importing modules, both in your code and the npm packages you depend on" - I took it to mean that I could import npm-installed packages using that prefix.

Thanks

No, regular npm modules just use their name 😅

node_compat works though, but there's a scary part about big trade-offs

node_compat accepts that? That's.. weird

No, sorry, it just accepts the node module without complaining about

assert

in this case

node:assert is an allowed module with the

nodejs_compat

compatibility flag!

All of these are the ones you'd prefix with

node:

https://developers.cloudflare.com/workers/runtime-apis/nodejs/

The wording for > and the npm packages you depend on. means that the npm packages you use, must import

node:buffer

, for example, instead of just

buffer

The npm library needs to use

node:

even with the

nodejs_compat

flag?

Yes

It's been a common practice (not specific to workers) for quite a while now, so most of the newer packages should already do that

All the node docs for any version greater than 14.x if my memory serves me correctly demonstrate importing

node:package

, for example

Got it, thanks for clearing that up!

Unfortunately this library doesn't use it. I can use a fatter non-node library or this one with polyfill. Or just update it and submit a PR

Yeah a PR or fork could easily do 🙂

I noticed that, sort of stealthily, better 25519 curve support was added to the crypto APIs in workers. Is there any estimate on when the related page in the docs will be updated? I can follow the spec it's based off of, but would be nice to have it there too for quick reference and to confirm if there's anything missing from the spec implementation