rate_limits.counted_in_memory: Deployable built for Workers would count its rate limits in each instance's memory

Deployable built for Workers would count its rate limits in each instance's memory.

Area 16, Built-in services; declinable; the next step is usually the agent's.

Until Redis's driver comes with caches, a deployable whose rate limits are counted in Redis counts them in its own memory, and a Worker runs as many instances as its traffic needs, none sharing it, so each counts on its own. A judgement call: Cloudflare's rate-limiting binding counts them across instances, or a decline line above the deployable keeps Redis, counting in memory until its driver comes. An edge on Workers counting in Redis:

example

application {    connections: {        cache: {            driver: Driver.redis        }    }    rate_limits: {        store: cache    }    deployables: {        edge: {            serves: [main]            target: Target.wasm        }    }}

jadpo checkcheck failed: 1 error, 1 file

error edge would count its rate limits in each instance's memory on Workers

--> app.jadpo:11:9

   | 8 |         store: cache   |                ----- Redis, whose driver isn't built yet11 |         edge: {   |         ^^^^ counts in memory13 |             target: Target.wasm   |                     ----------- built for Workers

reason: cache is a Redis connection, and Redis's driver comes with caches; until then each of a Worker's instances counts the rate limits in its own memory, which its other instances don't share, so a client whose requests reach several of them gets more than each limit.
next: Count them in Cloudflare's rate-limiting binding: declare a connection with driver: Driver.cloudflare_rate_limits and a namespace:, and name it in rate_limits: { store: }, or write decline rate_limits.counted_in_memory: "<why>" above it if this is deliberate (agent)
rule: rate_limits.counted_in_memory
help: https://jadpo.dev/docs/errors/rate_limits.counted_in_memory