#Volatile variables: env vars that don’t ...

1 messages · Page 1 of 1 (latest)

charred temple
#

I scrolled through it and to be totally honest the implementation doesn't make any sense at all

winter robin
#

oh no

charred temple
#

not in a way where I could just leave comments and it would be adjustable, it just doesn't make any sense

winter robin
#

Then I'm lost. I tried by hand first. Then LLM told me I messed up. Looks like the LLM also messed up

#

I think I just dont understand theseus enough, to even drive the LLM properly

#

Sorry for the slop

charred temple
#

it seems like it is very tied to the old pre-theseus world view or something? even though it's technically adapted

winter robin
#

I'll try from scratch

charred temple
#

Use 5.5 xhigh. Start with a single prompt along the lines of

I need you to read the cache expert skill reference docs in full. You need to understand the system like the back of your hand so that means you should also take a look at the code that is mentioned by each reference doc and understand that like it's the back of your hand. So you truly become a cache expert and an expert on this entire system. Do that now. Take your time. Read. Understand.

Then, do discussion on the requirements first and get a high-level design. Then ask for an implementation plan that goes over the changes on a per-file basis, with a description of each change in each file using appropriately detailed code snippets, which it should use to check the cohesiveness of the place with itself and with the system as a whole.

That's what I do for more complicated and involved changes like this anyways.

You have to understand it and tell it what to do though. It gives extremely good feedback on ideas but is still not good at generating ideas/plans from scratch, at least when it comes to tricky stuff like this.

winter robin
#

This is basically what I did the first time around (pre-theseus). I just made the mistake of assuming I could then tack on "main has changed significantly, understand deeply why, and transpose our original design goal & implementation onto the new architecture"

charred temple
winter robin
#

TLDR:

Use a dynamic input to strip the value from cache identity, store only a session-resource
handle on the container, and resolve/overlay the current value only at withExec runtime.

#

Slightly more detailed version of the TLDR:

Implement withVolatileVariable(name, value) as a non-secret session-resource-backed env
var.

The cached container stores only a stable handle derived from the parent container identity

  • env name, never the value. A dynamic input hook binds the current value to that handle
    before cache lookup, then rewrites the value arg to a sentinel so the value is excluded
    from DagQL recipe/cache identity.

Container gets VolatileVariables []{Name, VariableHandleResult}. withExec resolves those
handles only when the exec actually evaluates, overlays them into meta.Env after image env
and before secret env, and does not add them to secret redaction metadata.

Everything else stays non-visible: not in Config.Env, not in image export, not returned by
envVariable(s), and expand: true errors if it references a volatile name. Cache hits still
return cached exec output; reruns for other reasons see the latest bound volatile value.

charred temple