``` import wasm from './module.wasm'; const instance = await WebAssembly.instantiate(wasm, {}); ```

NNick Randall ``` import wasm from './module.wasm'; const instance = await WebAssembly.instant...

K

kian•7/3/23, 6:57 PM

I can't replicate any issues with this code personally

N

Nick RandallOP•7/3/23, 7:00 PM

I'm still debugging but I think what I'm realizing that that the Worker API for wasm is not the same as what is documented by MDN.

K

kian•7/3/23, 7:00 PM

It should be pretty much the same

K

kian•7/3/23, 7:00 PM

Workers doesn't support

instantiateStreaming

instantiateStreaming

instantiateStreaming

instantiateStreaming or passing a Buffer to either of them, but otherwise it's the same.

N

Nick RandallOP•7/3/23, 7:00 PM

For example, https://developer.mozilla.org/en-US/docs/WebAssembly/JavaScript_interface/instantiate says instaniate says that the promise returns an instance and a module

WebAssembly.instantiate() - WebAssembly | MDN

The WebAssembly.instantiate() function allows you to
compile and instantiate WebAssembly code. This function has two overloads:

K

kian•7/3/23, 7:01 PM

Scroll down

N

Nick RandallOP•7/3/23, 7:01 PM

In worker, it only returns the instance (and not object containing instance)

K

kian•7/3/23, 7:01 PM

You're looking at "Primary overload — taking Wasm binary code"

K

kian•7/3/23, 7:01 PM

You're actually using "Secondary overload — taking a module object instance"

N

Nick RandallOP•7/3/23, 7:02 PM

I see

K

kian•7/3/23, 7:13 PM

you can do bindings to an environment variable in workerd

K

kian•7/3/23, 7:13 PM

just not w/ wrangler

P

Phatso•7/3/23, 8:32 PM

I have a weird question about Wrangler and "Deploy with Workers"

I have a public project that I host publicly for free, but I add the option for anyone to host their own on cloudflare.

The "Deploy with Workers" button essentially clones the repo and deploys it to their cloudflare account using the

wrangler.toml

wrangler.toml

.
However, I have to bind KV (and soon, multiple R2 buckets) to the workers for them to function.
I do not want to ask the users to manually set this up on their own and edit their wrangler.toml for their fork (merge conflicts, making it harder for them to use the latest version of the app).

My Janky solution is to edit the included GitHub Action to find/create the KV required and manually add it to the

wrangler.toml

wrangler.toml

right before the

wrangler deploy

wrangler deploy

action runs:
https://github.com/CFC-Servers/gm_express_service/blob/main/.github/workflows/deploy.yml#L28

But now I'll need to do this for up to 5 buckets, too.

Is there any other way to do this?

K

kian•7/3/23, 8:44 PM

You can do the same with Wrangler - with the caveat that the bucket will be spawned close to the CI runners.

P

Phatso•7/3/23, 8:52 PM

Yeah I really need a way to create a bucket in all 5 of the major regions supported. I might have to use the S3 API inside the GH action...

B

bennycondon•7/4/23, 4:05 AM

I’ve just updated my wrangler version to

wrangler@beta

wrangler@beta

wrangler@beta

wrangler@beta, i.e.

wrangler@0.0.0-9ced24c9

wrangler@0.0.0-9ced24c9

wrangler@0.0.0-9ced24c9

wrangler@0.0.0-9ced24c9. This ensured I could use Wrangler 3 on macOS 11 “Big Sur” (see https://github.com/cloudflare/workers-sdk/issues/3457#issuecomment-1614424921).

I run my pages project with the command:

npx wrangler pages dev ./functions --local --live-reload --persist-to=./.wrangler --compatibility-date=2023-06-28 --d1=<BINDING_NAME>

npx wrangler pages dev ./functions --local --live-reload --persist-to=./.wrangler --compatibility-date=2023-06-28 --d1=<BINDING_NAME>

npx wrangler pages dev ./functions --local --live-reload --persist-to=./.wrangler --compatibility-date=2023-06-28 --d1=<BINDING_NAME>

npx wrangler pages dev ./functions --local --live-reload --persist-to=./.wrangler --compatibility-date=2023-06-28 --d1=<BINDING_NAME>

.

However, when hitting my API routes I now receive this warning:

Your worker created multiple branches of a single stream (for instance, by calling `response.clone()` or `request.clone()`) but did not read the body of both branches. This is wasteful, as it forces the system to buffer the entire stream of data in memory, rather than streaming it through. This may cause your worker to be unexpectedly terminated for going over the memory limit. If you only meant to copy the request or response headers and metadata (e.g. in order to be able to modify them), use the appropriate constructors instead (for instance, `new Response(response.body, response)`, `new Request(request)`, etc).

Your worker created multiple branches of a single stream (for instance, by calling `response.clone()` or `request.clone()`) but did not read the body of both branches. This is wasteful, as it forces the system to buffer the entire stream of data in memory, rather than streaming it through. This may cause your worker to be unexpectedly terminated for going over the memory limit. If you only meant to copy the request or response headers and metadata (e.g. in order to be able to modify them), use the appropriate constructors instead (for instance, `new Response(response.body, response)`, `new Request(request)`, etc).

Your worker created multiple branches of a single stream (for instance, by calling `response.clone()` or `request.clone()`) but did not read the body of both branches. This is wasteful, as it forces the system to buffer the entire stream of data in memory, rather than streaming it through. This may cause your worker to be unexpectedly terminated for going over the memory limit. If you only meant to copy the request or response headers and metadata (e.g. in order to be able to modify them), use the appropriate constructors instead (for instance, `new Response(response.body, response)`, `new Request(request)`, etc).

Your worker created multiple branches of a single stream (for instance, by calling `response.clone()` or `request.clone()`) but did not read the body of both branches. This is wasteful, as it forces the system to buffer the entire stream of data in memory, rather than streaming it through. This may cause your worker to be unexpectedly terminated for going over the memory limit. If you only meant to copy the request or response headers and metadata (e.g. in order to be able to modify them), use the appropriate constructors instead (for instance, `new Response(response.body, response)`, `new Request(request)`, etc).

I don’t use

response.clone()

response.clone()

response.clone()

response.clone() or

request.clone()

request.clone()

request.clone()

request.clone() anywhere in my pages project. Are there any other ways I could be creating multiple branches of a single stream?

S

Shirokawa•7/4/23, 6:29 AM

Trying to unit test my ts worker code with vitest, but I am bit lost on what is the right approach given the changes with miniflare v3 and wrangler (found some older blog posts that seem to be using miniflare 2 approaches, but not sure what the way to go is currently.)

Does something like this look correct (simplified example code)?

S

Shirokawa•7/4/23, 6:29 AM

import { expect, test } from "vitest";
import worker from "./worker";

const describe = setupMiniflareIsolatedStorage();

interface WorkerBindings {
  KV_NAMESPACE: KVNamespace;
  R2_BUCKET: R2Bucket;
}

const env: WorkerBindings = getMiniflareBindings();
const ctx: ExecutionContext = new ExecutionContext();

describe("Given a request", () => {
  test("when the URL path contains a valid KV key, correct value is returned", async () => {
    await env.KV_NAMESPACE.put("testKey", "testValue");
    const req = new Request<unknown, IncomingRequestCfProperties<unknown>>("https://example.com/kv/testKey");
    const res = await worker.fetch(req, env, ctx);
    expect(res.status).toEqual(200);
    expect(await res.text()).toEqual("testValue");
  });

  test("when the URL path contains a valid R2 key, correct value is returned", async () => {
    await env.R2_BUCKET.put("hello", "world");    
    const req = new Request<unknown, IncomingRequestCfProperties<unknown>>("https://example.com/r2/hello");
    const res = await worker.fetch(req, env, ctx);
    expect(res.status).toEqual(200);
    expect(await res.text()).toEqual("world");
  });
});

import { expect, test } from "vitest";
import worker from "./worker";

const describe = setupMiniflareIsolatedStorage();

interface WorkerBindings {
  KV_NAMESPACE: KVNamespace;
  R2_BUCKET: R2Bucket;
}

const env: WorkerBindings = getMiniflareBindings();
const ctx: ExecutionContext = new ExecutionContext();

describe("Given a request", () => {
  test("when the URL path contains a valid KV key, correct value is returned", async () => {
    await env.KV_NAMESPACE.put("testKey", "testValue");
    const req = new Request<unknown, IncomingRequestCfProperties<unknown>>("https://example.com/kv/testKey");
    const res = await worker.fetch(req, env, ctx);
    expect(res.status).toEqual(200);
    expect(await res.text()).toEqual("testValue");
  });

  test("when the URL path contains a valid R2 key, correct value is returned", async () => {
    await env.R2_BUCKET.put("hello", "world");    
    const req = new Request<unknown, IncomingRequestCfProperties<unknown>>("https://example.com/r2/hello");
    const res = await worker.fetch(req, env, ctx);
    expect(res.status).toEqual(200);
    expect(await res.text()).toEqual("world");
  });
});

import { expect, test } from "vitest";
import worker from "./worker";

const describe = setupMiniflareIsolatedStorage();

interface WorkerBindings {
  KV_NAMESPACE: KVNamespace;
  R2_BUCKET: R2Bucket;
}

const env: WorkerBindings = getMiniflareBindings();
const ctx: ExecutionContext = new ExecutionContext();

describe("Given a request", () => {
  test("when the URL path contains a valid KV key, correct value is returned", async () => {
    await env.KV_NAMESPACE.put("testKey", "testValue");
    const req = new Request<unknown, IncomingRequestCfProperties<unknown>>("https://example.com/kv/testKey");
    const res = await worker.fetch(req, env, ctx);
    expect(res.status).toEqual(200);
    expect(await res.text()).toEqual("testValue");
  });

  test("when the URL path contains a valid R2 key, correct value is returned", async () => {
    await env.R2_BUCKET.put("hello", "world");    
    const req = new Request<unknown, IncomingRequestCfProperties<unknown>>("https://example.com/r2/hello");
    const res = await worker.fetch(req, env, ctx);
    expect(res.status).toEqual(200);
    expect(await res.text()).toEqual("world");
  });
});

import { expect, test } from "vitest";
import worker from "./worker";

const describe = setupMiniflareIsolatedStorage();

interface WorkerBindings {
  KV_NAMESPACE: KVNamespace;
  R2_BUCKET: R2Bucket;
}

const env: WorkerBindings = getMiniflareBindings();
const ctx: ExecutionContext = new ExecutionContext();

describe("Given a request", () => {
  test("when the URL path contains a valid KV key, correct value is returned", async () => {
    await env.KV_NAMESPACE.put("testKey", "testValue");
    const req = new Request<unknown, IncomingRequestCfProperties<unknown>>("https://example.com/kv/testKey");
    const res = await worker.fetch(req, env, ctx);
    expect(res.status).toEqual(200);
    expect(await res.text()).toEqual("testValue");
  });

  test("when the URL path contains a valid R2 key, correct value is returned", async () => {
    await env.R2_BUCKET.put("hello", "world");    
    const req = new Request<unknown, IncomingRequestCfProperties<unknown>>("https://example.com/r2/hello");
    const res = await worker.fetch(req, env, ctx);
    expect(res.status).toEqual(200);
    expect(await res.text()).toEqual("world");
  });
});

S

Shirokawa•7/4/23, 6:29 AM

Is

setupMiniflareIsolatedStorage()

setupMiniflareIsolatedStorage()

setupMiniflareIsolatedStorage()

setupMiniflareIsolatedStorage() required in a situation like this? I tested using the vitest

describe

describe

describe

describe and as far as I could tell the tests ran the same.

S

Shirokawa•7/4/23, 6:29 AM

The

ExportedHandler

ExportedHandler

ExportedHandler

ExportedHandler interface used in the Worker docs exposes fetch optionally (

fetch?: ...

fetch?: ...

fetch?: ...

fetch?: ...), which adds some extra checking that

fetch

fetch

is defined in tests. I made a custom

ExportedHandler

ExportedHandler

ExportedHandler

ExportedHandler type with

fetch

fetch

required for the handler to avoid this. Is there a better approach?

Original message was deleted

S

Shirokawa•7/4/23, 8:01 AM

Thanks a lot! Is the current best practice to use

vitest-environment-miniflare": "2.x"

vitest-environment-miniflare": "2.x"

vitest-environment-miniflare": "2.x"

vitest-environment-miniflare": "2.x" until unit testing is supported in wrangler/miniflare 3? If not, how is everyone unit testing their workers at the moment with wrangler/miniflare 3?

L

lambrospetrou•7/4/23, 8:32 AM

Hey folks, just a bit of feedback, I spent 4-5 hours just trying to get a working setup for wrangler and Cloudflare Pages inside Github Codespaces. All sorts of linux package dependency incompatibilities (e.g.

libc++1

libc++1

libc++1

libc++1,

libunwind

libunwind

libunwind

libunwind), and then I had to resort to using

wrangler@beta

wrangler@beta

wrangler@beta

wrangler@beta in order for things to work out.
I know

workerd

workerd

is being actively worked on, but hopefully this will get more smooth down the line since the local DX is a bit annoying to having to sort out every few months...

Llambrospetrou Hey folks, just a bit of feedback, I spent 4-5 hours just trying to get a workin...

J

James•7/4/23, 1:08 PM

Yep thankfully

wrangler@beta

wrangler@beta

wrangler@beta

wrangler@beta resolves most of the dependency issues and unblocks many people now. There’s still a few regressions from v2, but it’s slowly getting there.

Wrangler 3 was a pretty rough experience for a lot of people, and the wrangler team has been made very aware of this.

I too am hopeful that better testing internally is a much stronger focus moving forward.

K

kian•7/4/23, 4:21 PM

Is your workers-types up to date?

K

kian•7/4/23, 4:54 PM

Ah, it's been fixed but not yet released

C

Cyb3r-Jak3•7/6/23, 1:48 AM

Has anyone else seen this error before?

FATAL ERROR: v8::ToLocalChecked Empty MaybeLocal.
 1: 0xb090e0 node::Abort() [node]
 2: 0xa1b60e node::FatalError(char const*, char const*) [node]
 3: 0xce178a v8::Utils::ReportApiFailure(char const*, char const*) [node]
 4: 0xb22165  [node]
 5: 0x1a68837 llhttp__internal_execute [node]
 6: 0xb252ad  [node]
 7: 0xbe50dd node::LibuvStreamWrap::OnUvRead(long, uv_buf_t const*) [node]
 8: 0xbe54c4  [node]
 9: 0x1558427  [node]
10: 0x1558c50  [node]
11: 0x155ee34  [node]
12: 0x154d058 uv_run [node]
13: 0xa43975 node::SpinEventLoop(node::Environment*) [node]
14: 0xbc7692 node::worker::Worker::Run() [node]
15: 0xbc7e28  [node]
16: 0x7f110c5a9b43  [/lib/x86_64-linux-gnu/libc.so.6]
17: 0x7f110c63ba00  [/lib/x86_64-linux-gnu/libc.so.6]
Aborted (core dumped)

FATAL ERROR: v8::ToLocalChecked Empty MaybeLocal.
 1: 0xb090e0 node::Abort() [node]
 2: 0xa1b60e node::FatalError(char const*, char const*) [node]
 3: 0xce178a v8::Utils::ReportApiFailure(char const*, char const*) [node]
 4: 0xb22165  [node]
 5: 0x1a68837 llhttp__internal_execute [node]
 6: 0xb252ad  [node]
 7: 0xbe50dd node::LibuvStreamWrap::OnUvRead(long, uv_buf_t const*) [node]
 8: 0xbe54c4  [node]
 9: 0x1558427  [node]
10: 0x1558c50  [node]
11: 0x155ee34  [node]
12: 0x154d058 uv_run [node]
13: 0xa43975 node::SpinEventLoop(node::Environment*) [node]
14: 0xbc7692 node::worker::Worker::Run() [node]
15: 0xbc7e28  [node]
16: 0x7f110c5a9b43  [/lib/x86_64-linux-gnu/libc.so.6]
17: 0x7f110c63ba00  [/lib/x86_64-linux-gnu/libc.so.6]
Aborted (core dumped)

FATAL ERROR: v8::ToLocalChecked Empty MaybeLocal.
 1: 0xb090e0 node::Abort() [node]
 2: 0xa1b60e node::FatalError(char const*, char const*) [node]
 3: 0xce178a v8::Utils::ReportApiFailure(char const*, char const*) [node]
 4: 0xb22165  [node]
 5: 0x1a68837 llhttp__internal_execute [node]
 6: 0xb252ad  [node]
 7: 0xbe50dd node::LibuvStreamWrap::OnUvRead(long, uv_buf_t const*) [node]
 8: 0xbe54c4  [node]
 9: 0x1558427  [node]
10: 0x1558c50  [node]
11: 0x155ee34  [node]
12: 0x154d058 uv_run [node]
13: 0xa43975 node::SpinEventLoop(node::Environment*) [node]
14: 0xbc7692 node::worker::Worker::Run() [node]
15: 0xbc7e28  [node]
16: 0x7f110c5a9b43  [/lib/x86_64-linux-gnu/libc.so.6]
17: 0x7f110c63ba00  [/lib/x86_64-linux-gnu/libc.so.6]
Aborted (core dumped)

FATAL ERROR: v8::ToLocalChecked Empty MaybeLocal.
 1: 0xb090e0 node::Abort() [node]
 2: 0xa1b60e node::FatalError(char const*, char const*) [node]
 3: 0xce178a v8::Utils::ReportApiFailure(char const*, char const*) [node]
 4: 0xb22165  [node]
 5: 0x1a68837 llhttp__internal_execute [node]
 6: 0xb252ad  [node]
 7: 0xbe50dd node::LibuvStreamWrap::OnUvRead(long, uv_buf_t const*) [node]
 8: 0xbe54c4  [node]
 9: 0x1558427  [node]
10: 0x1558c50  [node]
11: 0x155ee34  [node]
12: 0x154d058 uv_run [node]
13: 0xa43975 node::SpinEventLoop(node::Environment*) [node]
14: 0xbc7692 node::worker::Worker::Run() [node]
15: 0xbc7e28  [node]
16: 0x7f110c5a9b43  [/lib/x86_64-linux-gnu/libc.so.6]
17: 0x7f110c63ba00  [/lib/x86_64-linux-gnu/libc.so.6]
Aborted (core dumped)

I am using

unstable_dev

unstable_dev

and only getting this error when running in GitHub actions and not locally

D

DaniFoldi•7/6/23, 5:44 AM

Is this on node 16?

J

Jökull Sólberg•7/6/23, 7:32 AM

I am using Vercel CI for Next and wrangler to deploy my worker. Vercel takes 3.5 minutes and wrangler 30 seconds. Is there a way to synchronize their deployment or do I have to do this in 3 steps - a) deploy future compatible backend, 2) deploy frontend, 3) (optional) deploy deprecations for backend

I'd like to keep the Vercel CI if possible, It's quite nice. I also don't think next-on-pages is ready, but might be willing to give that a try again if it's progressed massively. Last I checked I couldn't access bindings and env

.

J

James•7/6/23, 9:08 AM

To add to that, bindings can be accessed via

process.env

process.env

and will be available when running through wrangler/deployed. In next dev, you could try using a proxy like https://github.com/james-elicx/cf-bindings-proxy

J

Jökull Sólberg•7/6/23, 9:10 AM

Oh wow ... this should be useful for SvelteKit too -- right?

JJökull Sólberg Oh wow ... this should be useful for SvelteKit too -- right?

J

James•7/6/23, 9:16 AM

I've never used svelte before so I wouldn't be able to say. This falls back to

process.env

process.env

in prod builds - if svelte uses that then yes. if not, i suppose it could probably be modified to accept a second parameter so that you can also pass in a custom variable to fallback to instead of

process.env

process.env

J

Jökull Sólberg•7/6/23, 9:17 AM

Reading next-on-pages --- not seeing information on how to use schedule and queue. I'm using that. Is there a way to use Pages to deploy this thing, but still have

export default {fetch,queue,schedule}

export default {fetch,queue,schedule}

export default {fetch,queue,schedule}

export default {fetch,queue,schedule} ?

JJökull Sólberg Reading next-on-pages --- not seeing information on how to use schedule and queu...

J

James•7/6/23, 9:24 AM

Pages doesn't support using those two - you should have a separate worker for them. Even if Pages did support them, there would not be a way to use them with NOP at the moment

J

Jökull Sólberg•7/6/23, 9:31 AM

My issue is mainly synchronous deployment. There's a drift of 2 minutes because of the CI difference (nice job on that btw ... workers deploy FAST)

J

Jökull Sólberg•7/6/23, 9:31 AM

It's not a massive issue - we'll launch and live with it. Just have to manually orchestrate migrations and deployments etc.

``` import wasm from './module.wasm'; const instance = await WebAssembly.instantiate(wasm, {}); ```

Similar Threads

Similar Threads

Similar Threads