makes sense, thank you

does this mean my variables i set in dashboard will be overriden? 😨

my config is just this

You can use

--keep-vars

to keep the ones set in the dashboard

Or you can put the vars in your wrangler.toml to keep them without needing the flag

is this ok still?

> Or you can put the vars in your wrangler.toml

so i thought about this option although i don't get how to securely have them in the file

via process.env or something perhaps

If you added secrets, they'll be ok

If you added normal env vars, you should put them in your wrangler.toml really

The warning is just there in case you do something destructive. If it was just secrets, you're ok 🙂

Thanks I totally missed that, I did manage to find the settings for workers, however I couldn't find Routes for pages or R2, planning on deploying static files that would benefit from the cdn cache.

I think I have a workaround which is to monkey patch

<script>

on the html

ahh yea you can't do that with Pages or R2, neither work with wildcards like that. You could use a worker fetching from R2 if the extra worker invocation costs don't bother you

well yeah the extra invocation cost kinda bother me a bit, but I guess I have no other option, I will just return a minimal html from the worker that contains metadata to monkey patch a

<script>

that grabs the static files from

static.domain.com

R2

Where can I ask something about Zero Trust?

#1104040620948992090 or #909458221419356210

Is it possible to deploy a worker function with

wrangler

and then invoke an older deployed version that hasn't been updated to the new code?

I'm asking because it seems that this has happened to me. If so, I'm curious if there's like a period of time that I should wait before invoking my worker functions to ensure that the new deployment has fully saturated all of the edge locations

Unless there is an incident, it should take less than a minute to update everywhere

Ah, okay, I definitely invoked it a lot faster than that. Thanks

hi, I found call

controller.error

in method

write

for WritableStream will not end stream which causes websocket never close. I tested in Chrome,

controller.error

can trigger

catch

block.. Below is the sample code for this.

js
export default {
    async fetch(request, env, ctx) {
        const upgradeHeader = request.headers.get('Upgrade');
        if (!upgradeHeader || upgradeHeader !== 'websocket') {
            return new Response('not websocket', { status: 200 });
        }
        const webSocketPair = new WebSocketPair();
        const [client, webSocket] = Object.values(webSocketPair);
        webSocket.accept();
        let count = 0;
        const readableStream = new ReadableStream({
            start(controller) {
                setInterval(() => {
                    controller.enqueue(count);
                    count++;
                }, 500)

            },
            async pull(controller) {
            },
            cancel() {
                console.log('ReadableStream was canceled.');
            },
        });

        const writableStream = new WritableStream({
            write(chunk, controller) {
                console.log(`Received data: ${chunk}`);
                webSocket.send(`Received data: ${chunk}`);
                if (chunk === 3) {
                    controller.error('eroorooororo')
                    return;
                }

            },
            close() {
                console.log('WritableStream was closed');
            },
            abort() {
                console.log('WritableStream was aborted');
            }
        });
        readableStream.pipeTo(writableStream).catch((error) => {
            console.log('pipeTo error', error);
            webSocket.close();
        });
        webSocket.addEventListener('close', () => {
            console.log('close');
        });
        return new Response(null, {
            status: 101,
            webSocket: client,
        });
    }
};

```js const [client, webSocket] = Object.values(webSocketPair);```looks like quite a precarious assumption...

I'm not sure what the properties are, but it'd be much safer to write something like```js const {client, webSocket} = webSocketPair;```

Wait, the actual CF documentation encourages that... Why 🤔

The properties are literally keys called 0 and 1 rather than being an array

Yeah, I just Google'd the for ... in (

Object.values

follows the same ordering) sorting algorithm... Turns out it has a special exception for integer-looking keys where it sorts those in ascending order before the named keys... That's... Interesting TIL

Ignore me. But returning an object instead of an array as well... Interesting design I guess