Skip to content

fix: scope asModule cache per-session to prevent cross-worktree collision#12901

Draft
eunomie wants to merge 1 commit intodagger:mainfrom
eunomie:fix-multi-playground
Draft

fix: scope asModule cache per-session to prevent cross-worktree collision#12901
eunomie wants to merge 1 commit intodagger:mainfrom
eunomie:fix-multi-playground

Conversation

@eunomie
Copy link
Copy Markdown
Member

@eunomie eunomie commented Apr 3, 2026

When running dagger call from two different git worktrees simultaneously against the same engine daemon, the content-digest cache in dagql could return a Module from a different session. That Module carries a path-dependent ContextDirectoryPath from the wrong worktree, causing "module not found" errors.

Scope the asModule resolver with CachePerSession so each session gets its own result, preventing the content-digest cache from leaking path-dependent state across sessions.

@eunomie eunomie requested a review from sipsma April 3, 2026 15:44
…sion

When running `dagger call` from two different git worktrees simultaneously
against the same engine daemon, the content-digest cache in dagql could
return a Module from a different session. That Module carries a
path-dependent ContextDirectoryPath from the wrong worktree, causing
"module not found" errors.

Scope the asModule resolver with CachePerSession so each session gets its
own result, preventing the content-digest cache from leaking path-dependent
state across sessions.

Signed-off-by: Yves Brissaud <yves@dagger.io>
@eunomie eunomie force-pushed the fix-multi-playground branch from 5c9939d to 1a1da24 Compare April 3, 2026 15:45
@sipsma
Copy link
Copy Markdown
Contributor

sipsma commented Apr 3, 2026

@eunomie did you confirm this change specifically fixes the problem for you? i.e. you can repro the issue on the previous commit from main before this one, but this commit specifically fixes it.

Just checking because I don't see why caching asModule per-session could possibly make a difference given moduleSource itself is already cache per-client. But if it does make a difference then it's low-risk enough.

The real fix for all this is #11856 because it completely eliminates the possibility of the problem fundamentally, but if this change unblocks you I'm fine with it in the meantime.

@eunomie
Copy link
Copy Markdown
Member Author

eunomie commented Apr 16, 2026

I'm putting it back to draft, waiting to #11856 to fix it. It's sometimes annoying but not a huge problem for now

@eunomie eunomie marked this pull request as draft April 16, 2026 09:26
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants