🐛 BUG: Can write+read to KV namespace from CLI (wrangler) but can't read from worker

[gvanto]

Which Cloudflare product(s) does this pertain to?

KV

What version(s) of the tool(s) are you using?

3.5.0 wrangler

What version of Node are you using?

18.15.0

What operating system are you using?

Mac

Describe the Bug

I created new KV namespace using wrangler, as outlined here:
https://developers.cloudflare.com/workers/wrangler/workers-kv/#create-a-kv-namespace-with-wrangler

I used the --preview field because it was complaining I am in dev environment and therefor need to use it.
I then added the identical id={preview_id} field into the wrangler.toml file, because of same issue as here:
#3621

I have put a key/value (hello > world) using the wrangler CLI and can retrieve it using the CLI:

[12:07:42][~/code/test/redirector]$(⚡master) npx wrangler kv:key get --binding=SOURCES_TARGETS "hello"
Output: world

As per the CF docs, using the following code to try and retrieve the value from my worker:

let target = await SOURCES_TARGETS.get("hello");

then I get error:

I came across post somewhere saying the docs are outdated, and I need to use env., so trying that:

let target = await env.SOURCES_TARGETS.get("hello");

but this just returns null ...

wrangler.toml file:

Please provide a link to a minimal reproduction

No response

Please provide any relevant error logs

{binding} is not defined

[RamIdeas]

Hi @gvanto! Please provide your worker code (or a link to the whole repo) so that we can have the context to help you

[gvanto]

Ok so the fix was this (the worker can now access the KV storage using env.{BINDING} (docs also need to be updated to reflect this):
npx wrangler dev --remote

Why this flag is needed is not clear (is the KV storage running remote? doesn't seem to be, as a .wrangler/state/kv folder is created locally with db data in it)

[jspspike]

@gvanto KV namespace should work in both remote and local dev server. Could you provide your worker code as a reproduction?

Did you define env in your fetch handler like so?

export default {
  async fetch(
    request,
    env,
    ctx,
  ) {
    console.log(env.SOURCES_TARGET)
  }
}

Also when you run wrangler dev do you get output like this when the dev server starts?

Your worker has access to the following bindings:
- KV Namespaces:
`- SOURCES_TARGETS: <preview_id>   

[gvanto]

@gvanto KV namespace should work in both remote and local dev server. Could you provide your worker code as a reproduction?

Did you define env in your fetch handler like so?

export default {
  async fetch(
    request,
    env,
    ctx,
  ) {
    console.log(env.SOURCES_TARGET)
  }
}

Yes I am.

Also when you run wrangler dev do you get output like this when the dev server starts?

Your worker has access to the following bindings:
- KV Namespaces:
`- SOURCES_TARGETS: <preview_id>   

So, when I start it without '--remote', I get the following:

But then the KV storage doesn't work at all (null returned for getting the key, as in my first post).

When I start with --remote, KV access works. But why, is not clear:
I created the KV namespace with --preview, which seems to suggest it is running locally (not in production on the CF cloud). From the docs:

Think the docs need to be more clear on what "--preview" (for KV) does and "--remote" does for wrangler ?

[jspspike]

The docs should probably better explain. Normally when you run wrangler dev it runs locally. If you use --remote it will run on the edge. The --preview flag is used to interact with the preview KV namespace rather than the production KV namespace (both on the edge). Although it looks like you set the preview and actual kv namespace to the same thing in the toml, so they would both interact with the same namespace.

So you say that when you run env.SOURCES_TARGETS.get("hello") you get a null response. That's normally for something without a value set. Have you tried setting the value first? Either in your worker or via wrangler kv:key put hello val --local --namespace-id <namespace id>

[gvanto]

Thanks @jspspike for your helpful explanation (this should be added to the docs).

env.SOURCES_TARGETS.get("hello") works (value retrieved) when running the worker with --remote, so all good.

Thanks for your help, much appreciated.