Yes, in the dashboard I declared variable PIC to my r2 namespace

How big is the file you’re uploading

53kb

OK, so I got it working by doing this:

const buffer = await fileUploaded.arrayBuffer();
  const bucketPut = await env.PIC.put(uuid, buffer, bucketPutOptions);

However: you probably want to stream the contents to r2 and this will buffer it in the worker, and I have no idea why it works locally. Edit: Here's what you want:

const bucketPut = await env.PIC.put(
    uuid,
    fileUploaded.stream(),
    bucketPutOptions
  );

what is the difference/impact between buffer method and stream method?

That gets a

readableStream

from the uploaded File and passes it along, so you're not buffering the file contents.

Thank you! Thank yoU!

this must be a quirk of the differences between the local dev env and production. when pages gets support for

--experimental-local

maybe your original code will stop working locally

This code is specific to my app, but you could do something similar.

type UsesMiddlewareProps = {
  url: string;
};

// Requests with these strings should not have middleware added to them.
export const undesiredPaths = [
  ".css",
  ".ico",
  ".js",
  ".png",
  ".jpeg",
  ".jpg",
  ".svg",
  ".wepb",
  "/fonts/"
];

export function getUsesMiddleware({url} : UsesMiddlewareProps): boolean {
  return ! undesiredPaths.some((undesiredString) => {
    return url.includes(undesiredString);
  });
}

I call

getUsesMiddleware

with a URL to decide if I need to do extra stuff with the request.

Continuing the logs discussion from #779390076219686943 … this morning as I was debugging, it seems like half the time I `wrangler pages publish`ed, the resulting deploy would never return any logs. Half the time it did. So i would connect, do some requests, and if no logs came through, I’d publish again and try again. Over about 10 deploys, it worked half the time.

Also, that wrangler table for deploys is terrible if your window isn’t wide enough because you can’t copy/paste the deploy url easily 🙂

I believe they're currently changing what does tables for wrangler

Hey is there another way to access environment variables other than

context.env

? I'm thinking of instantiating a faunadb client in a module then importing that, but then I'd have to dependency inject the secrets from where-ever I'm calling it from and I'm not sure about that. Alternatively I'm thinking of instantiating the client in middleware which would work but there's more logic I'd like to write associated with the faunadb client / other services. Also how would I pass that down in the middleware,

context.env

is that the practice? is there another preferred way of instantiating services to use across a cloudflare pages codebase? :)

You're pretty spot-on with

context.env

and passing it around. If it's something you plan to re-use in many places, you may want to extract it to your own Pages Plugin: https://developers.cloudflare.com/pages/platform/functions/plugins/ But that doesn't change much - it's essentially just reusable middleware.

ah that makes sense! I'll look into plugins thanks!

If you want to pass stuff between middlewares, you should use

context.data

(it's just an object - you can put whatever there)

planning on passing a class instance with methods, what's the difference between

env

and

data

? also I'm concerned about compatibility in the future for example if I set a

env.HOUSE

for example then cloudflare releases a binding called

env.HOUSE

, would that be an issue?

env is for your bindings, I wouldn't advise you pollute it. Data is specifically for passing whatever between middleware

(also you would have to add the

HOUSE

binding yourself - it wouldn't suddenly just appear and overwrite your functions)

ah ok I'm just thinking because

env.ASSETS

is a default binding right? I'm guessing cloudflare doesn't want to pollute it either

that's the only one - and it's specific to pages, not workers as a whole

that was present from the beginning of functions existing, so it wasn't a breaking change

ok that makes sense

thanks :)

I monitor the age of my workers and noticed that one function didn't evict after pushing the new code for the same function. This is an isolated event. The worker was 7000 seconds old, and still alive not being purged. Have you seen such behaviour before?

Is there a way with pages directory mode to create a queue consumer?

Not at this time, hopefully in future 🙂

Okay thanks for the heads up 👍 Is it possible in advanced mode?

No I don't believe so - you would need Pages support directly, and that generally doesn't happen while a product is in beta.