#KV config in wrangler.toml did not get passed to deployed worker

32 messages · Page 1 of 1 (latest)

glass ruin
#

I have been testing out using env tags in wrangler on a mini project recently and found that I needed to manually deploy the code, then add in the bindings in cloudflare UI even though they were all in the toml file.

Is this normal, as I thought the toml file would do that config for you?

my vars get pushed fine, its just the [env.dev.vars.kv_namespaces] part that doesn't. It all matches up but I have to add it manually.

using the latest version of wrangler 2.8.1

lunar bison
#

I think you're looking for [env.dev.kv_namespaces] and not [env.dev.vars.kv_namespaces] - note the lack of vars

glass ruin
#

funny, ok, I will try that, using that version I had, it still shows up in the list of available things my environment can read from when I boot wrangler locally.

#

I tried what you said and it still doesn't work

#
[env.dev]
name = "x-dev"

[env.dev.vars]
name = "dev"
TOKEN = "cef"

kv_namespaces = [
    { binding = "CONFIG_KV", id = "SOME_ID" }
]

I tried it the other way you said but it is said it had to be an array. I had it the other way with fields under the bracketed heading.

#

when I do "deploy:dev": "wrangler publish src/index.ts --env dev", this is my package.json script

#

it will deploy the worker (this is from scratch, I cleaned the deployment) but no KV bindings are applied from the toml

lunar bison
#

Try moving it under env.dev. Kv_namespaces is top-level, not under vars

glass ruin
#

so under the [env.dev] block?

#

TOML is.... challenging.

#

😄

lunar bison
#

Yeah - under that block

glass ruin
#

thats it. thankyou

#

I have to say your docs on this in the dev portal aren't the clearest on this.

#

and if its in the wrong place, wrangler doesn't seem to do much error checking or warning.

lunar bison
#

Agreed, environments in general are a bit confusing at the moment. Hopefully this’ll improve in future once deployments get fleshed out

glass ruin
#

are dev and prod really used?

lunar bison
#

They’re arbitrary names - you could name them red and blue. It’ll just create separate workers with the env name appended

glass ruin
#

because I see this is deployed as production in the workers side of things regardless

#

yeah I thought so.

lunar bison
#

Yeah… that’s the old ‘service environments’ you’re seeing in the dashboard which was retired

#

It’s all a bit messy right now but work is happening to tighten it up soontm

glass ruin
#

ok, yes, I remember in the past there was more of a use of that.

#

thanks

#

I had another question, around best practices for using values from said KV

#

is it just best to read each time or use a cache to save it for optimal reading

#

I don't want to use durable objects right now

#

I was hoping there was a way to do it using KV and optionally cache

#

it's just a simple blob of json I might need to change occassionally (like a state machine)

lunar bison
#

KV reads will be cached after the first one based on your cacheTtl

#

Using cache APIs directly won’t be any faster, but it might be cheaper since cache is free.

glass ruin
#

ok, thanks @lunar bison I appreciate your help on this!