cole
CDCloudflare Developers
•Created by cole on 4/23/2025 in #pages-help
Pages Repository Limit
Hello. I am hitting the same issue discussed in this thread: https://discord.com/channels/595317990191398933/1351610490069057638/1351610490069057638
We are using a monorepo as well from the same repository. Hit the limit of 10 pages projects deployed from the repository. We have customers waiting, and I can't find the "limit increase" form... so I thought I would reach out here.
Account ID is:
804f65dff7cae7a9f4fee96ca2f659581 replies
CDCloudflare Developers
•Created by cole on 3/24/2025 in #workers-help
Root directory does not restrict builds for pages
2 replies
CDCloudflare Developers
•Created by cole on 3/22/2025 in #workers-help
I am either crazy... or I found a subtle/silent way to break queue producing
Hello. I will do more digging into this as I am able... but wanted to share in case someone can provide direction for how to gather more details:
- I have a worker that consumes from Queue A and produces into Queue B
- That worker reaches out to supabase using the supabase-js library
- After the supabase upsert/select... the
env.QUEUE_B.send() method ends the invocation
I can env.QUEUE_B.send() multiple times up until that point... but once I supabase.schema().upsert().select().single() (which returns without error), the next env.QUEUE_B.send() ends the program with no errors, no warnings, nothing. try/catch gives nothing ,etc.
This sounds nuts, but it seems like there is some weird / latent global state that supabase or some wrapper code is modifying that changes behavior.
Is there any way to gather more info on this type of thing and what is happening? I had to get something shipped, so I switched to fetching against the other worker directly rather than the async / queueing approach.1 replies
CDCloudflare Developers
•Created by cole on 2/25/2025 in #workers-help
Variables not available in pages build?
7 replies
CDCloudflare Developers
•Created by cole on 2/21/2025 in #workers-help
Websockets with Workers
Howdy y'all! I have a worker that is functioning as a websocket server. Everything works fantastically:
- locally / in dev
- in production if I use a CLI to interact
The second I wire up a browser to it, things start failing though. And what's worse, the failing has almost no details anywhere that I can find. The connection succeeds and then immediately closes. No logs on the backend, and logs on the frontend are code 1006 ("i dunno what happened").
Has anyone seen this before? Any ideas where to dig in? It feels like either browser security (no luck on making CORS permissive) or something strange Cloudflare is doing.
9 replies
CDCloudflare Developers
•Created by cole on 1/11/2024 in #workers-help
R2 Access Via Domain is Down?
32 replies
CDCloudflare Developers
•Created by cole on 12/28/2023 in #workers-help
form data with itty-router-openapi
I have a form submission going through a worker built with itty-router-openapi. If I submit the data via a POST request with standard
application/json, everything works swimmingly. Use data.body just like the examples, etc.
However, if I submit the data as a application/x-www-form-urlencoded, then I get nothing.
Moreover, if I try to read FormData() off of the request, then I get "body has already been read." Presumably the body is read during the body sanitization / verification / schema-matching done by itty-router.
Any recommendations for which direction to go here? Is there a way to access FormData through itty-router-openapi?
https://github.com/cloudflare/itty-router-openapi2 replies