Worker refusing to recognize KV namespace even after binding

I'm trying to increment a key in my namespace from my worker and I keep getting red squiggly lines under my namespace's name along with the message "Cannot find name [NAMESPACE]". I've already added the KV namespace binding in my worker settings. Is there something else I'm missing? EDIT: I've also just been using the Cloudflare dashboard to bind my variable from my namespace, and I'm using Cloudflare's online text editor to edit my worker.
No description
No description
10 Replies
Mackenly
Mackenly9mo ago
Assuming your binding is configured within your weangler.toml, you'll need to reference your database using the environment variable. Bindings aren't directly in scope by default, instead they're attached in the env variable. If you have it bound via the dashboard, you'll need to use the variable name listed for your binding. (Still accessed in code through env, but I don't think you have to worry about the wrangler.toml since it's already bound) See documentation on configuring wrangler.toml and using KV in your project: https://developers.cloudflare.com/workers/runtime-apis/kv#reference-kv-from-workers Example toml from the docs:
name = "worker"

# ...

kv_namespaces = [
{ binding = "TODO", id = "06779da6940b431db6e566b4846d64db" }
]
name = "worker"

# ...

kv_namespaces = [
{ binding = "TODO", id = "06779da6940b431db6e566b4846d64db" }
]
Code example from the docs:
export default {
async fetch(request, env, ctx) {
// Get the value for the "to-do:123" key
// NOTE: Relies on the `TODO` KV binding that maps to the "My Tasks" namespace.
let value = await env.TODO.get("to-do:123");

// Return the value, as is, for the Response
return new Response(value);
},
};
export default {
async fetch(request, env, ctx) {
// Get the value for the "to-do:123" key
// NOTE: Relies on the `TODO` KV binding that maps to the "My Tasks" namespace.
let value = await env.TODO.get("to-do:123");

// Return the value, as is, for the Response
return new Response(value);
},
};
KV · Cloudflare Workers docs
Workers KV is a global, low-latency, key-value data store. It stores data in a small number of centralized data centers, then caches that data in …
Tin Cap
Tin Cap9mo ago
You're using the syntax for service workers. Is your code a module worker? The syntax is different. See https://developers.cloudflare.com/workers/learning/migrate-to-module-workers/#bindings-in-es-modules-format
Migrate from Service Workers to ES Modules · Cloudflare Workers docs
This guide will show you how to migrate your Workers from the Service Worker format to the ES modules format.
honzabit
honzabit9mo ago
Based on the naming of the KV, I would suggest you switch to DOs instead, as KVs are eventually consistent and cannot be used for the purpose of "counting" hits. Check my reply here on another thread, regarding this misconception: https://discord.com/channels/595317990191398933/1155937065926672384/1156581670661652590
Lando Calrissian
Thank you guys for the help! I fixed this by referencing the namespace by the variable name instead of the namespace name. I'm still getting red squiggly lines under my code, but it works.
Lando Calrissian
Using different names now btw And Visit_Number is one of my keys inside of VSTCNT
Tin Cap
Tin Cap9mo ago
Beware the warning above about KV not being good for counting You risk having stale reads, so if you got lots of visits at once, your count might not go up high enough. The issue is that your current count will be 0. You get a visit. The code reads the current count as 0, increments it to 1, and writes 1 to KV.
You get another visit shortly after, it reads the current count as 0 (because the previous write hasn't propagated everywhere y et), increments it to 1, and writes 1 to KV. You got two visits, but only record 1 in KV. Oops. The closer together your traffic is, the higher the risk of miscounting it. It may or may not be a big issue for you, but something to be aware of. KV is not good for scenarios where you need writes to be immediately readable with the new value.
Lando Calrissian
I didn't think of this... Then at some point I'm gonna try putting in new keys for every user's ID and getting a count of how many keys I have in my namespace to represent a true visit count. Thanks for catching that
Tin Cap
Tin Cap9mo ago
That doesn't sound like a great pattern either because you'll need to read 10,000 items if you have 10,000 visitors, but it could get you by for a while while your site is small.