#Just a quick question, are env var

1 messages · Page 1 of 1 (latest)

fiery crypt
#

I'm not following what you are referring to by "env var" exactly

#

I'm presuming I can help because I heard "session" and "secrets", but let me know if this is something else outside my area 😄

mellow imp
fiery crypt
#

I recall hitting the same thing a while back in earlier iterations, so think this is a known issue? cc @willow marlin @peak dagger to confirm it's not new

mellow imp
#

I'll dig into it a bit deeper, but I was wondering if, in general, env variable in the engine (e.g the ones we set with withEnvVariable) are scoped per session or is it just secrets that are scoped per sessions ?

#

Thanks for your help Erik 🙏

fiery crypt
mellow imp
# fiery crypt What do you mean by "scoped per session"?

sorry, per client*

My understanding of session being: "a dagger client (cli), connected to an engine" -> the session being this connection, during the lifetime of this connection

My assumption is that I can have 2 CLIs talking to the same engine, and they shouldn't find a way to access to each other's env vars?

(reason why you implemented the accessor, for the secrets, to scope the access to those secrets per session, if I'm correct ?)

fiery crypt
#

Yeah they shouldn't get cache hits on the plaintext values of secrets from other clients. There is some test coverage for all that, but not around the llm secret stuff specifically. You're seeing that you get old secret values from earlier connected clients for the values read from the llm env secrets?

fiery crypt
#

Think I know what's happening

#

It should be a quick fix, I'll send something to try in a few

mellow imp
fiery crypt
fiery crypt
#

Tested manually and can see that at least the model doesn't pick up cached values from other sessions. Presumably that means the rest is good too but would appreciate a double check if you have time

#

I'll work on an integ test for it

fiery crypt
#

Added that test, should be good to review+ship now

mellow imp