Erik Sipsma

This one is still appearing ([GHA](https://github.com/dagger/dagger/actions/runs/11259583691/job/31308896759)) ([Traces](https://dagger.cloud/dagger/traces/a800de1a9b253530bdc80a5773484f26))

Another recent occurrence https://dagger.cloud/dagger/traces/15c22afdc0ae043aed5e80b9282135f8 It seems like the `on failure` test in particular is prone to this (might be the only one?) cc @aluzzardi

While working on the filesync stuff I started hitting this flake locally relatively consistently by running: ``` ./hack/with-dev go test -v -run='TestModule/TestDaggerTerminal|TestModule/TestDaggerUp' -count=10 -parallel=8 ./core/integration/ ``` can't repro locally unless...

> The "REP", the protocol that is private today but we are considering making public @shykes We don't need to make all of that public. The only thing we need...

> I'm good with the sequencing here, but just to nitpick - I think that one of the reasons to design these together, is that the `docker-image://` in `_EXPERIMENTAL_DAGGER_RUNNER_HOST` today...

I am not immediately sure why the engine tests are not getting run automatically in this PR? Just running locally in the meantime, will revisit after release is done.

I am still quite confused why the engine tests are not running here. All I see in Actions is this workflow with no jobs stuck in Queued: https://github.com/dagger/dagger/actions/runs/10000394190 My yaml...

> Thought of a potentially even simpler fix to https://github.com/dagger/dagger/issues/7900 than what I described in the most recent comment there: just set the hostname of nested clients to a digest...

Currently letting `TestLegacy` run in a loop for a good while to verify flake is gone. Will do the same for the module tests as a whole. GHA is having...

Locally: * `TestLegacy` passed in a loop for an hour * `TestModule` has passed twice in a row (takes ~30m locally, so gonna keep it looping for a while longer)...