Pages projects are automatically deployed globally - you don't get to choose where they are.

I

Isaac McFadyenOP•11/27/24, 12:41 AM

If your restrictions mandate you can only deploy to US/Canada then Pages isn't the right platform for you, unfortunately.

IIsaac McFadyen Pages projects are automatically deployed globally - you don't get to choose whe...

D

dev•11/27/24, 2:25 AM

I’ll have to check if we can get away with a region specific DB but still use pages..

N

naourass•11/27/24, 1:14 PM

Any specific version of Node.js you guys recommend when developing locally using Wrangler's

getPlatformProxy

getPlatformProxy

and miniflare/workerd ?

Nnaourass Any specific version of Node.js you guys recommend when developing locally using...

J

James•11/27/24, 2:15 PM

>=18 should be good. I personally recommend latest LTS, which is currently 22.x

N

naourass•11/27/24, 4:51 PM

Looks like there's a timeout issue for the proxy process of D1 simulation in the latest versions of wrangler's

getPlatformProxy

getPlatformProxy

:

const cfPlatformProxy = await getPlatformProxy();
const db = drizzle(cfPlatformProxy.env.DB);

// Do some a few seconds long computation here...

const res = await db.select().from(myTable);

const cfPlatformProxy = await getPlatformProxy();
const db = drizzle(cfPlatformProxy.env.DB);

// Do some a few seconds long computation here...

const res = await db.select().from(myTable);

const cfPlatformProxy = await getPlatformProxy();
const db = drizzle(cfPlatformProxy.env.DB);

// Do some a few seconds long computation here...

const res = await db.select().from(myTable);

const cfPlatformProxy = await getPlatformProxy();
const db = drizzle(cfPlatformProxy.env.DB);

// Do some a few seconds long computation here...

const res = await db.select().from(myTable);

/home/naourass/web_exp/phoenix-astro-next/node_modules/undici/index.js:112
        Error.captureStackTrace(err, this)
              ^

TypeError: fetch failed
    at Object.fetch (/home/naourass/web_exp/phoenix-astro-next/node_modules/undici/index.js:112:15)
    at fetch3 (/home/naourass/web_exp/phoenix-astro-next/node_modules/miniflare/src/http/fetch.ts:90:19)
    at ProxyClientBridge.dispatchFetch (/home/naourass/web_exp/phoenix-astro-next/node_modules/miniflare/src/index.ts:1647:20)
    at ProxyStubHandler.#parseAsyncResponse (/home/naourass/web_exp/phoenix-astro-next/node_modules/miniflare/src/plugins/core/proxy/client.ts:339:15)
    at D1PreparedQuery.get (/home/naourass/web_exp/phoenix-astro-next/node_modules/src/d1/session.ts:223:16) {
  cause: SocketError: other side closed
      at Socket.onSocketEnd (/home/naourass/web_exp/phoenix-astro-next/node_modules/undici/lib/client.js:1118:22)
      at Socket.emit (node:events:529:35)
      at Socket.emit (node:domain:489:12)
      at endReadableNT (node:internal/streams/readable:1400:12)
      at process.processTicksAndRejections (node:internal/process/task_queues:82:21) {
    code: 'UND_ERR_SOCKET',
    socket: {
      localAddress: '127.0.0.1',
      localPort: 57506,
      remoteAddress: undefined,
      remotePort: undefined,
      remoteFamily: undefined,
      timeout: undefined,
      bytesWritten: 1091,
      bytesRead: 1783105
    }
  }
}

/home/naourass/web_exp/phoenix-astro-next/node_modules/undici/index.js:112
        Error.captureStackTrace(err, this)
              ^

TypeError: fetch failed
    at Object.fetch (/home/naourass/web_exp/phoenix-astro-next/node_modules/undici/index.js:112:15)
    at fetch3 (/home/naourass/web_exp/phoenix-astro-next/node_modules/miniflare/src/http/fetch.ts:90:19)
    at ProxyClientBridge.dispatchFetch (/home/naourass/web_exp/phoenix-astro-next/node_modules/miniflare/src/index.ts:1647:20)
    at ProxyStubHandler.#parseAsyncResponse (/home/naourass/web_exp/phoenix-astro-next/node_modules/miniflare/src/plugins/core/proxy/client.ts:339:15)
    at D1PreparedQuery.get (/home/naourass/web_exp/phoenix-astro-next/node_modules/src/d1/session.ts:223:16) {
  cause: SocketError: other side closed
      at Socket.onSocketEnd (/home/naourass/web_exp/phoenix-astro-next/node_modules/undici/lib/client.js:1118:22)
      at Socket.emit (node:events:529:35)
      at Socket.emit (node:domain:489:12)
      at endReadableNT (node:internal/streams/readable:1400:12)
      at process.processTicksAndRejections (node:internal/process/task_queues:82:21) {
    code: 'UND_ERR_SOCKET',
    socket: {
      localAddress: '127.0.0.1',
      localPort: 57506,
      remoteAddress: undefined,
      remotePort: undefined,
      remoteFamily: undefined,
      timeout: undefined,
      bytesWritten: 1091,
      bytesRead: 1783105
    }
  }
}

/home/naourass/web_exp/phoenix-astro-next/node_modules/undici/index.js:112
        Error.captureStackTrace(err, this)
              ^

TypeError: fetch failed
    at Object.fetch (/home/naourass/web_exp/phoenix-astro-next/node_modules/undici/index.js:112:15)
    at fetch3 (/home/naourass/web_exp/phoenix-astro-next/node_modules/miniflare/src/http/fetch.ts:90:19)
    at ProxyClientBridge.dispatchFetch (/home/naourass/web_exp/phoenix-astro-next/node_modules/miniflare/src/index.ts:1647:20)
    at ProxyStubHandler.#parseAsyncResponse (/home/naourass/web_exp/phoenix-astro-next/node_modules/miniflare/src/plugins/core/proxy/client.ts:339:15)
    at D1PreparedQuery.get (/home/naourass/web_exp/phoenix-astro-next/node_modules/src/d1/session.ts:223:16) {
  cause: SocketError: other side closed
      at Socket.onSocketEnd (/home/naourass/web_exp/phoenix-astro-next/node_modules/undici/lib/client.js:1118:22)
      at Socket.emit (node:events:529:35)
      at Socket.emit (node:domain:489:12)
      at endReadableNT (node:internal/streams/readable:1400:12)
      at process.processTicksAndRejections (node:internal/process/task_queues:82:21) {
    code: 'UND_ERR_SOCKET',
    socket: {
      localAddress: '127.0.0.1',
      localPort: 57506,
      remoteAddress: undefined,
      remotePort: undefined,
      remoteFamily: undefined,
      timeout: undefined,
      bytesWritten: 1091,
      bytesRead: 1783105
    }
  }
}

/home/naourass/web_exp/phoenix-astro-next/node_modules/undici/index.js:112
        Error.captureStackTrace(err, this)
              ^

TypeError: fetch failed
    at Object.fetch (/home/naourass/web_exp/phoenix-astro-next/node_modules/undici/index.js:112:15)
    at fetch3 (/home/naourass/web_exp/phoenix-astro-next/node_modules/miniflare/src/http/fetch.ts:90:19)
    at ProxyClientBridge.dispatchFetch (/home/naourass/web_exp/phoenix-astro-next/node_modules/miniflare/src/index.ts:1647:20)
    at ProxyStubHandler.#parseAsyncResponse (/home/naourass/web_exp/phoenix-astro-next/node_modules/miniflare/src/plugins/core/proxy/client.ts:339:15)
    at D1PreparedQuery.get (/home/naourass/web_exp/phoenix-astro-next/node_modules/src/d1/session.ts:223:16) {
  cause: SocketError: other side closed
      at Socket.onSocketEnd (/home/naourass/web_exp/phoenix-astro-next/node_modules/undici/lib/client.js:1118:22)
      at Socket.emit (node:events:529:35)
      at Socket.emit (node:domain:489:12)
      at endReadableNT (node:internal/streams/readable:1400:12)
      at process.processTicksAndRejections (node:internal/process/task_queues:82:21) {
    code: 'UND_ERR_SOCKET',
    socket: {
      localAddress: '127.0.0.1',
      localPort: 57506,
      remoteAddress: undefined,
      remotePort: undefined,
      remoteFamily: undefined,
      timeout: undefined,
      bytesWritten: 1091,
      bytesRead: 1783105
    }
  }
}

Is there some way to make the proxy process persist till I call cfPlatformProxy.dispose(), or should I just recreate the proxy process each time using getPlatformProxy() after a long computation as a workaround for now?

N

naourass•11/27/24, 5:43 PM

BTW this error wasn't happening in the previous versions of wrangler before the 2 or 3 latest updates.

N

naourass•11/28/24, 11:49 AM

Not sure why but looks like this workaround helped bypass that error (recalling

drizzle(db)

drizzle(db)

drizzle(db)

drizzle(db) and waiting for ~1sec):

const cfPlatformProxy = await getPlatformProxy();
let db = drizzle(cfPlatformProxy.env.DB);

// Do some a few seconds long computation here...

db = drizzle(cfPlatformProxy.env.DB);
await new Promise(resolve => setTimeout(resolve, 1500));

const res = await db.select().from(myTable);

const cfPlatformProxy = await getPlatformProxy();
let db = drizzle(cfPlatformProxy.env.DB);

// Do some a few seconds long computation here...

db = drizzle(cfPlatformProxy.env.DB);
await new Promise(resolve => setTimeout(resolve, 1500));

const res = await db.select().from(myTable);

const cfPlatformProxy = await getPlatformProxy();
let db = drizzle(cfPlatformProxy.env.DB);

// Do some a few seconds long computation here...

db = drizzle(cfPlatformProxy.env.DB);
await new Promise(resolve => setTimeout(resolve, 1500));

const res = await db.select().from(myTable);

const cfPlatformProxy = await getPlatformProxy();
let db = drizzle(cfPlatformProxy.env.DB);

// Do some a few seconds long computation here...

db = drizzle(cfPlatformProxy.env.DB);
await new Promise(resolve => setTimeout(resolve, 1500));

const res = await db.select().from(myTable);

W

Walshy•11/28/24, 11:50 PM

can you expand? logs?

W

Walshy•11/29/24, 12:16 AM

Your custom build command is an npm script which runs wrangler build... which then triggers the custom build command and there's the loop

W

Walshy•11/29/24, 12:17 AM

Custom build command is for like your own handling of esbuild. I'd recommend just running your dry run as part of some npm script

J

James•11/29/24, 12:23 AM

Has anyone seen a case where bindings to D1 or DO don't work when running wrangler with --test-scheduled flag? I get silent failures when trying to access D1 or D0 in either case, only locally with cron tasks on a worker. But the same worker codebase runs fine with the bindings when I run it as a regular worker for both fetch or queue incoming requests.

I've tested this at its most raw level. When I run the cron task locally, it starts fine, runs fine until I use either binding. Even for a basic statement such as:
await env.BINDING.exec("select * from users");

Fails silently with or without debugging on. I tested, and the --persist-to is set correctly, where I have a shared folder for D1/DO storage.

Again, this worker access all bindings fine running under the queue/fetch context, just not when running --test-scheduled

JJames Has anyone seen a case where bindings to D1 or DO don't work when running wrangl...

J

James•11/29/24, 3:08 PM

Tried reinstalling and upgrading wrangler, no dice. My Hacky workaround is to call the same code from a queue message instead of the cron simulator.

Sounds like a wrangler bug.

V

Vero•11/29/24, 4:04 PM

Hey all! Just a heads-up: we’re changing the format of the @Wrangler office hours. Going forward, instead of a call, the Wrangler team will answer your questions directly in this channel during the event.
https://discord.gg/cloudflaredev?event=1303336766237048853

M

mani123•11/29/24, 4:10 PM

hi all, im can use WasmJs from Kotlin in Wrangler?

Mmani123 hi all, im can use WasmJs from Kotlin in Wrangler?

M

mani123•11/29/24, 5:50 PM

https://github.com/bashor/kotlin-worker-hello-world/tree/master

GitHub

GitHub - bashor/kotlin-worker-hello-world

Contribute to bashor/kotlin-worker-hello-world development by creating an account on GitHub.

N

neoney•11/29/24, 10:03 PM

im running

wrangler dev

wrangler dev

on a worker and I can't access the bindings made from anotehr worker

N

neoney•11/29/24, 10:03 PM

http://localhost:6284/workers

N

neoney•11/29/24, 10:03 PM

is unable to connect

N

neoney•11/29/24, 10:05 PM

N

neoney•11/29/24, 10:14 PM

now i get this

N

neoney•11/29/24, 10:15 PM

its supposed to be a http binding

N

neoney•11/29/24, 10:16 PM

ok i fixed it, turns out if you log the binding it errors but it works fine

C

Constantin•11/30/24, 12:05 PM

any ideea how build variables like

CF_PAGES_COMMIT_SHA

CF_PAGES_COMMIT_SHA

CF_PAGES_COMMIT_SHA

CF_PAGES_COMMIT_SHA and

CF_PAGES_BRANCH

CF_PAGES_BRANCH

CF_PAGES_BRANCH

CF_PAGES_BRANCH can be extracted in the qwik framework?

having them like:

export const useServerTimeLoader = routeLoader$(async ({ env }) => {
  return {
    date: new Date().toISOString(),
    commit: env.get("CF_PAGES_COMMIT_SHA"),
    branch: env.get("CF_PAGES_BRANCH"),
  };
});

export const useServerTimeLoader = routeLoader$(async ({ env }) => {
  return {
    date: new Date().toISOString(),
    commit: env.get("CF_PAGES_COMMIT_SHA"),
    branch: env.get("CF_PAGES_BRANCH"),
  };
});

export const useServerTimeLoader = routeLoader$(async ({ env }) => {
  return {
    date: new Date().toISOString(),
    commit: env.get("CF_PAGES_COMMIT_SHA"),
    branch: env.get("CF_PAGES_BRANCH"),
  };
});

export const useServerTimeLoader = routeLoader$(async ({ env }) => {
  return {
    date: new Date().toISOString(),
    commit: env.get("CF_PAGES_COMMIT_SHA"),
    branch: env.get("CF_PAGES_BRANCH"),
  };
});

is not working

C

Constantin•11/30/24, 1:46 PM

does CF_PAGES_COMMIT_SHA and CF_PAGES_BRANCH are missing from workers ? (i'm using the new git integration)

W

Walshy•11/30/24, 4:27 PM

no, the id is not private

W

Walshy•11/30/24, 4:28 PM

it means nothing to anyone else, it cannot be used by anyone else

W

Walshy•11/30/24, 4:28 PM

the whole of wrangler.toml is safe to share wherever

W

Walshy•11/30/24, 4:28 PM

?pings also

S

SuperHelpflare•11/30/24, 4:28 PM

Please do not ping community members for non-moderation reasons. Doing so will not solve your issue faster and will make people less likely to want to help you.

WWalshy the whole of wrangler.toml is safe to share wherever

敖

敖律风•12/1/24, 4:01 AM

thankyou~

J

jokester•12/1/24, 3:11 PM

I'm trying to understand how

wrangler dev

wrangler dev

uses chrome dev tools to inspect worker requests. But I can't see the picture yet.

The code suggests it uses a patched build of

chrome-devtools

chrome-devtools

chrome-devtools

chrome-devtools . But I can't locate how wrangler starts chrome and talk to it.

Does anyone happen to have a hint? Thanks for any help:love:

J

jokester•12/1/24, 3:20 PM

Thanks I got that name too

J

jokester•12/1/24, 3:21 PM

I may found an entrypoint.
https://github.com/cloudflare/workers-sdk/blob/ff8f5ae03cd4a71bf7b468fcf3cd28bf064059ab/packages/wrangler/src/dev/hotkeys.ts#L4 This seems to be the "d" hotkey handler.

GitHub

workers-sdk/packages/wrangler/src/dev/hotkeys.ts at ff8f5ae03cd4a71...

Home to Wrangler, the CLI for Cloudflare Workers® - cloudflare/workers-sdk

J

jokester•12/1/24, 3:25 PM

Then in

openInspector()

openInspector()

openInspector()

openInspector() it just opens an webpage at

https://devtools.devprod.cloudflare.dev/js_app

https://devtools.devprod.cloudflare.dev/js_app

https://devtools.devprod.cloudflare.dev/js_app

https://devtools.devprod.cloudflare.dev/js_app
I don't understand how the page could communicate with a local process orz

W

Walshy•12/1/24, 4:29 PM

https://github.com/cloudflare/workers-sdk/blob/main/packages/wrangler/src/dev/inspect.ts#L254
https://github.com/cloudflare/workers-sdk/blob/ff8f5ae03cd4a71bf7b468fcf3cd28bf064059ab/packages/wrangler/templates/startDevWorker/InspectorProxyWorker.ts#L475-L611

J

jokester•12/1/24, 4:53 PM

wow I couldn't find that
So

js_app

js_app

js_app

js_app page is but a webpage built on devtools code. It just talk to local WS in devtools protocol.
This is insanely cool thanks

O

oof2win2•12/1/24, 7:53 PM

i've been using wrangler dev for a while. just today i started getting errors like

Failed to establish a new connection: [Errno 61] Connection refused

Failed to establish a new connection: [Errno 61] Connection refused

Failed to establish a new connection: [Errno 61] Connection refused

Failed to establish a new connection: [Errno 61] Connection refused (when trying to connect to :8787 via fetch). this has never happened to me before. is there any solution to this?

O

oof2win2•12/1/24, 8:38 PM

like i spin up wrangler, GET requests work, then i send in a POST and it breaks - wrangler doesn't log anything anymore and it is unresponsive - i can't even exit, i need to kill it

O

oof2win2•12/1/24, 8:39 PM

and this is the code i have setup - there's no way it should break

export default {
  async fetch(req, env) {
    if (req.method !== "POST")
      return Response.json({ message: "Method Not Allowed" }, { status: 405 });
    return Response.json({ status: "OK" }, { status: 200 });
  }
}

export default {
  async fetch(req, env) {
    if (req.method !== "POST")
      return Response.json({ message: "Method Not Allowed" }, { status: 405 });
    return Response.json({ status: "OK" }, { status: 200 });
  }
}

export default {
  async fetch(req, env) {
    if (req.method !== "POST")
      return Response.json({ message: "Method Not Allowed" }, { status: 405 });
    return Response.json({ status: "OK" }, { status: 200 });
  }
}

export default {
  async fetch(req, env) {
    if (req.method !== "POST")
      return Response.json({ message: "Method Not Allowed" }, { status: 405 });
    return Response.json({ status: "OK" }, { status: 200 });
  }
}

A

amlcodes•12/2/24, 5:44 AM

is there a way i can test my api and cf services /bindings in development without having to rely on a completely remote environment? I need to test my trpc hono worker using the r2 binding to hit the actual r2 store, not local. --remote causes my localhost cors to not work, and apparently chrome doesnt allow you to visit any page with HSTS instead of HTTPS which is what ngrok will give you on a subdomain, so i can't test with ngrok from a subdomain

K

kue•12/3/24, 1:12 PM

Is there anyone here who experienced missing entry-point error when using

cloudflare/wrangler-action@v3

cloudflare/wrangler-action@v3

cloudflare/wrangler-action@v3

cloudflare/wrangler-action@v3?

Here are my workflows config that I inherit from the documentation:

name: Deploy staging

on:
  push:
    branches:
      - main

jobs:
  cloudflare:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      deployments: write
    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - uses: pnpm/action-setup@v4
        with:
          version: 8

      - name: Deploy to Cloudflare Pages
        uses: cloudflare/wrangler-action@v3
        with:
          apiToken: ${{ secrets.CLOUDFLARE_API_TOKEN }}
          accountId: ${{ secrets.CLOUDFLARE_ACCOUNT_ID }}
          gitHubToken: ${{ secrets.GITHUB_TOKEN }}
          packageManager: pnpm

name: Deploy staging

on:
  push:
    branches:
      - main

jobs:
  cloudflare:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      deployments: write
    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - uses: pnpm/action-setup@v4
        with:
          version: 8

      - name: Deploy to Cloudflare Pages
        uses: cloudflare/wrangler-action@v3
        with:
          apiToken: ${{ secrets.CLOUDFLARE_API_TOKEN }}
          accountId: ${{ secrets.CLOUDFLARE_ACCOUNT_ID }}
          gitHubToken: ${{ secrets.GITHUB_TOKEN }}
          packageManager: pnpm

name: Deploy staging

on:
  push:
    branches:
      - main

jobs:
  cloudflare:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      deployments: write
    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - uses: pnpm/action-setup@v4
        with:
          version: 8

      - name: Deploy to Cloudflare Pages
        uses: cloudflare/wrangler-action@v3
        with:
          apiToken: ${{ secrets.CLOUDFLARE_API_TOKEN }}
          accountId: ${{ secrets.CLOUDFLARE_ACCOUNT_ID }}
          gitHubToken: ${{ secrets.GITHUB_TOKEN }}
          packageManager: pnpm

name: Deploy staging

on:
  push:
    branches:
      - main

jobs:
  cloudflare:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      deployments: write
    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - uses: pnpm/action-setup@v4
        with:
          version: 8

      - name: Deploy to Cloudflare Pages
        uses: cloudflare/wrangler-action@v3
        with:
          apiToken: ${{ secrets.CLOUDFLARE_API_TOKEN }}
          accountId: ${{ secrets.CLOUDFLARE_ACCOUNT_ID }}
          gitHubToken: ${{ secrets.GITHUB_TOKEN }}
          packageManager: pnpm

The weird things is, when I specifcy the full command

pages deploy PATH --project-name=kaget --branch=main

pages deploy PATH --project-name=kaget --branch=main

pages deploy PATH --project-name=kaget --branch=main

pages deploy PATH --project-name=kaget --branch=main the result has duplicate project name which leads to error no such file or directory

W

Walshy•12/3/24, 1:23 PM

You do want

pages deploy <path>

pages deploy <path>

pages deploy <path>

pages deploy <path> as the command but you don't seem to be building the site in the Action which is why the

dist

dist

folder seems missing

WWalshy You do want `pages deploy <path>` as the command but you don't seem to be buildi...

K

kue•12/3/24, 1:44 PM

Ahh my bad, thank you for catching that. I think I need a break haha

F

flyingshoes•12/3/24, 4:15 PM

Anyone seeing an increased error rate of

Rate limited. Please wait and consider throttling your request speed [code: 10000]

Rate limited. Please wait and consider throttling your request speed [code: 10000]

Rate limited. Please wait and consider throttling your request speed [code: 10000]

Rate limited. Please wait and consider throttling your request speed [code: 10000] ? We started seeing increased instances of this.

F

flyingshoes•12/3/24, 4:19 PM

is the rate limiting applied on an account level? We are working on an enterprise level, so there are multiple teams developing under this account.

Original message was deleted

F

flyingshoes•12/3/24, 7:58 PM

cool -- sent out a support ticket.

Original message was deleted

F

flyingshoes•12/3/24, 9:11 PM

question -- I got it increased, but it was for my user. I'm a bit confused though. We are running

wranger deploy

wranger deploy

wranger deploy

wranger deploy in CI (gh actions), so I don't think there's reference to my username in that environment. Or am I missing osmething?

W

Walshy•12/3/24, 9:13 PM

You're right to be confused, it is confusing (sorry) - rate limits are per-user not per-account. So your user (the one you sign in with) is what was rate limited.
It's the same way API tokens were per-user until we recently introduced account level ones.

Pages projects are automatically deployed globally - you don't get to choose where they are.

Similar Threads

Similar Threads

Similar Threads