This bit?

Oh, I see what you mean

I can't try anything since I don't have the add-ons

Increment counter when is after the response comes in do you want to reduce the counter (for example failed reqs)

I guess none of these will really work for it

hmm is there a way I can detect if it's CF doing the rate limiting, or their backend?

I kinda just relied on Cloudflare being able to ratelimit their own product haha

Not sure why the Worker isn't an option but from the docs, it can't

Probably response headers, if they have any that their origin adds that no-longer appear when you get 429'd - but you could also be ratelimited at another layer between them that also doesn't add them.

We blame discord for not applying different rate limits by cf-worker but not even cloudflare does it

btw for what it is worth we call

supabase.auth.getUser(jwt)

from a Worker and have never once been rate limited or gotten any error response

yep if we make our own tokens we don't get rate limiting as much

ah it is for creating? that makes more sense

yes. I figured out a cool trick where I use the user's password as a API key, which works perfectly with our billing model (since our pricing will be per "seat"/user/bot if you have a team with >1 members). We set the password to a JWT that's signed with a ECDSA (ES256) key, so we can validate it quickly before wasting time forwarding it to Supabase. By using it as a password, we get built in "revocation" too.

I'd assume its either not rate limited or rate limited by project and not ip

per seat pricing models tho

we're aiming for $1/day while the "alternative" is >$10/day. 😛

hmm the nodejs debugger for Workers can't show requests?

Is it possible to retain apps when running workers?

I doubt it, apps isnt really maintained anymore so it acts in weird ways

Response status: 429
Response headers: {
  "access-control-allow-origin": "*",
  "alt-svc": "h3=\":443\"; ma=86400, h3-29=\":443\"; ma=86400",
  "cf-cache-status": "DYNAMIC",
  "cf-ray": "7c4ab23d588ddb15-MIA",
  "connection": "keep-alive",
  "content-length": "40",
  "content-type": "application/json",
  "date": "Tue, 09 May 2023 14:40:12 GMT",
  "sb-gateway-version": "1",
  "server": "cloudflare",
  "strict-transport-security": "max-age=2592000; includeSubDomains",
  "vary": "Origin, Accept-Encoding",
  "via": "kong/2.8.1",
  "x-kong-proxy-latency": "0",
  "x-kong-upstream-latency": "0"
}

Does this mean the rate limiting is applied outside of Cloudflare?

it's returning headers from something behind CF, so yeah

Id say so yeah

Supabase uses Kong for their API gateway

Will

CF-Connecting-IP

be set to

2a06:98c0:3600::103

if the subrequest target domain is on CF, but the subdomain is not proxied by CF? https://developers.cloudflare.com/fundamentals/get-started/reference/http-request-headers/#cf-connecting-ip-in-worker-subrequests

It's just if it's cross-zone or not

If I create a worker that connects go a web socket (wss) to lesson / watch for updates. Will it get shutdown or does it stay running as long as there a connection to the wss?

It depends on if there is a connection to the worker or not