#cross check pollution?
1 messages · Page 1 of 1 (latest)
thanks
dont know how concerning it is
from yes to 10
recap for the thread context: The fc83c54 commit was not actually created by Solomon, but likely the automatic merge commit created for the CI run for the workspaces branch. My CI run for a different branch at the same time ran into this module not found error referring to the other branch's merge commit
<@&785926252749651978> for visibility
👀 some buildkit de-dup ghosts maybe? sounds like something Erik fixed in the past for some other scenarios
something about serving local dependencies when that dependency is cached from another client?
or actively being served for another session?
||maybe same thing, manifesting slightly differently?:
- https://dagger.cloud/vito/checks/github.com/vito/dagger@24f8114b80b8101e24a7f5d15a7b57feaf30807a?check=test-split%3Atest-module-runtimes&listen=9a317fc2037b58f7&listen=8c21c43174d53d12&listen=d0a31cc5bfdac380&listen=5baaa5195b6b2561&listen=6ac996ce74ed7dfe
- but this time that commit doesn't even exist! maybe it's from a different repo entirely?! that's evidence at least
||
||oh duh i just looked at the wrong repo - it's here: https://github.com/vito/dagger/commit/24f8114b80b8101e24a7f5d15a7b57feaf30807a (vito, not dagger)
those errors make sense then, i guess these tests just don't pass on forks - false alarm||
I was able to repro
shared the repro with @kindred mulch
chasing the 👻 now
it happens randomly if you run the same check from two different remote refs in the same engine
since the module source is exactly the same Erik is guessing that there's some dedup / caching stuff happening there that might return the other session's reference depending on timing