🐛 BUG: "can't use ".." to break out of starting directory" when using Service Bindings in monorepo

[wilsonpage]

Which Cloudflare product(s) does this pertain to?

Miniflare

What version(s) of the tool(s) are you using?

3.20231218.1 [miniflare]

What version of Node are you using?

20

What operating system are you using?

Mac

Describe the Bug

I'm attempting to use Miniflare to run one app (app-2) with a second app (app-1) as a Service Binding. The docs are a little thin here, so I'm not sure if I'm defining the workers in the correct way.

return new Miniflare({
  port: 4000,

  workers: [
    {
      name: 'app-1',
      scriptPath: 'dist/index.js',
      modules: true,

      serviceBindings: {
        APP_2: 'app-2',
      },
    },
    {
      name: 'app-2',
      scriptPath: resolvePath(__dirname, '../app-2/dist/index.js'),
      modules: true,

      durableObjects: {
        MyDurableObject: 'MyClass',
      },
    },
  ],
});

In doing this I'm getting the error:

workerd/util/symbolizer.c++:98: warning: Not symbolizing stack traces because $LLVM_SYMBOLIZER is not set. To symbolize stack traces, set $LLVM_SYMBOLIZER to the location of the llvm-symbolizer binary. When running tests under bazel, use `--test_env=LLVM_SYMBOLIZER=<path>`.
workerd/jsg/util.c++:281: error: e = kj/filesystem.c++:315: failed: expected parts.size() > 0 [0 > 0]; can't use ".." to break out of starting directory
stack: 1028e4c07 1028e3963 1028e383f 1008c776f 100b7ece3 100da687f 100db41ef 100db4083 100877e67 10087ddc7 1008815c3 10087ff13 100871b03 100871733 100871653 10087163b 1028fb9ff 1028fbd47 1028fa4a7 1028fa277 1008641af 182aed0df; sentryErrorContext = jsgInternalError
service core:user:rate-limiter: Uncaught Error: internal error

Notably: can't use ".." to break out of starting directory

I've tried various other approaches (eg. importing a Miniflare instance from app-2 and calling it programatcally), but it results in the same error. It feels like I'm battling against the framework here for what I imagine is a common project structure.

• Is there a way to define the Miniflare CWD? If so I could have it execute in the parent directory.
• For now I will probably hack around this, but just wanted to leave an issue here to confirm there wasn't a better way.

Cheers 🍺

Please provide a link to a minimal reproduction

No response

Please provide any relevant error logs

No response

[mrbbot]

Hey! 👋 I'm planning to add a rootPath option as part of #4490. In the meantime, you should be able to get around this issue by setting modulesRoot to resolvePath(__dirname, "..") in addition to your current configuration.

[hansottowirtz]

@mrbbot We have the same error, setting modulesRoot to a higher directory doesn't solve it. We're now just doing:

script: await readFile(scriptPath, "utf-8"),
scriptPath: "./index.mjs" // doesn't exist

[mrbbot]

@hansottowirtz Hmmm, setting just scriptPath: scriptPath should work in your case. 😕 Does the script you're passing to Miniflare contain any imports? Could you share the full error you're seeing?

[hansottowirtz]

It doesn't work when setting scriptPath: scriptPath. Yes, the script contains a dynamic import to cloudflare:sockets. It seems like the script file needs to be in the same directory tree as the script that sets up Miniflare. (Our script is in ../worker/dist/index.mjs.)

This is the error (same regardless of whether we're adding script: await readFile(scriptPath)):

capnp compile log.capnp -oc:capnp
*** Uncaught exception ***
kj/filesystem.c++:315: failed: expected parts.size() > 0; can't use ".." to break out of starting directory
stack: 7fc5f136d17b 7fc5f136f49a 5583e897a940 7fc5f14fda7d 7fc5f14fdab2 7fc5f14d8eaa 7fc5f14db191 7fc5f14f5571 7fc5f14fd223 7fc5f14fd28e 7fc5f14d9d7a 7fc5f14d99b0 7fc5f14da711 7fc5f14dfffc 7fc5f14e7e8a 7fc5f14e8d02 7fc5f14f9585 7fc5f14fb065 7fc5f14feea6 7fc5f14ff373 5583e8983781 5583e8983ad0 7fc5f1389467 7fc5f138a7a4
make: *** [Makefile:220: capnp/log.capnp.c] Error 1

[izidormaklary]

Hey @mrbbot ,
We created a minimalistic reproduction of our issue in case you are interested.
Only need to run yarn and yarn start, and the error shall be thrown.
Here is the repo

[izidormaklary]

@mrbbot did you have the chance to look at it?

[mrbbot]

Hey! Thanks for the ping. I haven't yet, will try look at this in the next week. 👍

[mrbbot]

Hey! 👋 Put up a PR to fix this. In the meantime seems like this isn't a problem if you path.resolve() all your paths before passing them to new Miniflare(), something like the following should work today:

const mf = new Miniflare({
	modules: true,
	modulesRoot: path.resolve(".."),
	scriptPath: path.resolve("../worker.mjs"),
});

[izidormaklary]

Hey! Thanks for looking into it, it works well this way 👍