My issue is that I have N clients

[sullen ingot]

I see, yeah I didn't consider the N clients aspect and the fact that's it's mutable state (of sorts) does make it more awkward to model with dagql operations, though still possible.

The thing that I care about a lot is that it should not be implemented by doing sync reads/writes from/to the client. Besides perf of --cloud, that's gonna lead to a world of misery when it comes to parallel operations stomping over each other.

It should be read once when the client starts, mutated server-side throughout the session, and then written back once when the session gracefully stops.

You could absolutely do that with dagql operations, via like _currentLockfile.pinContainerImage("foo", "bar") (except via dagql.Sever.Select), but you'd need void types since it's just a mutation. So yeah I agree that feels awkward.

The alternative is to store the lockfile on daggerSession (in ./engine/server/session.go) as part of session state. Then you can add methods to the dagger server + this interface used throughout core that expose lockfile reading + writing. Then just need to find the right place to hook in the final export at the end of the session (maybe the /shutdown endpoint?)

• This definitely feels the cleanest to me, I'd suggest this

[odd temple]

@sullen ingot here is Codex's best attempt at addressing your concerns 😛 https://gist.github.com/shykes/03ef3b40abe6338c3d0b3be7244e1807

(I think it's aligned with what we were already saying?)

[sullen ingot]

No it's confused and is contradicting itself

I'm saying there's two independent mutually exclusive paths:

1. do it through dagql
2. do it through session state

Both are viable, and at first I was thinking dagql would be best, but the alternative is probably cleaner

The thing that I care about a lot is that it should not be implemented by doing sync reads/writes from/to the client. Besides perf of --cloud, that's gonna lead to a world of misery when it comes to parallel operations stomping over each other.

It should be read once when the client starts, mutated server-side throughout the session, and then written back once when the session gracefully stops.
That's the important invariant.

And the implementation I'm suggesting is:

The alternative is to store the lockfile on daggerSession (in ./engine/server/session.go) as part of session state. Then you can add methods to the dagger server + this interface used throughout core that expose lockfile reading + writing. Then just need to find the right place to hook in the final export at the end of the session (maybe the /shutdown endpoint?)

• store the lockFile on daggerSession
• read it from at most once per-session (lazy init)
• ensure read/write of current session's lockfile is guarded by an rwmutex also stored on daggerSession
• expose read/write of current session's lockfile through methods on Server
  • i.e. see all the methods that start on line 1376 of engine/server/session.go which work by finding the caller's client and/or session, along with corresponding methods exposed on the interface on line 41 of core/query.go. That's pre-existing art and the existing pattern you can use to expose this functionality to callers in core/ and core/schema/
• ensure that when the main client shuts down the lockfile is exported back to it if it was read and updated
  • probably makes sense to do this in the /shutdown endpoint