playwright-java icon indicating copy to clipboard operation
playwright-java copied to clipboard

[BUG] Cannot find module package/lib/cli/cli.js

Open vemv opened this issue 1 year ago • 3 comments

System info

  • Playwright Version: [v1.31.0]
  • Operating System: Mac
  • Browser: All
  • Other info:

After a long-running session, a simple, unadorned Playwright.create() can start failing with:

com.microsoft.playwright.PlaywrightException: Failed to read message from driver, pipe closed.

	at com.microsoft.playwright.impl.PipeTransport.poll(PipeTransport.java:75)
	at com.microsoft.playwright.impl.Connection.processOneMessage(Connection.java:175)
	at com.microsoft.playwright.impl.ChannelOwner.runUntil(ChannelOwner.java:109)
	at com.microsoft.playwright.impl.Connection.sendMessage(Connection.java:119)
	at com.microsoft.playwright.impl.ChannelOwner.sendMessage(ChannelOwner.java:102)
	at com.microsoft.playwright.impl.Connection$Root.initialize(Connection.java:79)
	at com.microsoft.playwright.impl.Connection.initializePlaywright(Connection.java:152)
	at com.microsoft.playwright.impl.PlaywrightImpl.createImpl(PlaywrightImpl.java:52)
	at com.microsoft.playwright.impl.PlaywrightImpl.create(PlaywrightImpl.java:35)
	at com.microsoft.playwright.Playwright.create(Playwright.java:110)
	at com.microsoft.playwright.Playwright.create(Playwright.java:114)
Caused by: java.io.EOFException
	at com.microsoft.playwright.impl.ReaderThread.readIntLE(PipeTransport.java:110)
	at com.microsoft.playwright.impl.ReaderThread.readMessage(PipeTransport.java:139)
	at com.microsoft.playwright.impl.ReaderThread.run(PipeTransport.java:125)

It took me a long while to realise what was going on.

On stdout, which can be logged to a separate place relative to that of Java exceptions, I noticed:

node:internal/modules/cjs/loader:1050
  throw err;
  ^

Error: Cannot find module '/private/var/folders/yc/h50n8fgn0h79y848sfkr942h0000gn/T/playwright-java-17403553361898517108/package/lib/cli/cli.js'
    at Module._resolveFilename (node:internal/modules/cjs/loader:1047:15)
    at Module._load (node:internal/modules/cjs/loader:893:27)
    at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:81:12)
    at node:internal/main/run_main_module:23:47 {
  code: 'MODULE_NOT_FOUND',
  requireStack: []
}

So the issues that I would pinpoint/suggest are:

  • the Java exception doesn't provide a hint of what might be going on
    • in particular, it's not safe to assume that Java exceptions will be printed to the same place than stdout/stderr, so relying on node.js output alone is not self-contained
  • '/private/var/folders/yc/h50n8fgn0h79y848sfkr942h0000gn/T/playwright-java-17403553361898517108/package/lib/cli/cli.js' was gone, for whatever reason
    • hint 1: this was a very long-running session
      • are these Unix tmp files?
    • hint 2: I ran node commands in this directory during this time
      • may a node invocation spoil playwright's node?
    • neither 'hint' is necessarily conclusive - I just hope they help

After restating the JVM session, the issue was gone. Therefore it's hard to reproduce, sorry.

Thanks - V

vemv avatar May 29 '23 21:05 vemv

On stdout, which can be logged to a separate place relative to that of Java exceptions, I noticed:

This is stderr output which is indeed maybe printed to a different place.

the Java exception doesn't provide a hint of what might be going on

  • in particular, it's not safe to assume that Java exceptions will be printed to the same place than stdout/stderr, so relying on node.js output alone is not self-contained

We can probably also include a few last stderr lines into the exception. Currently stderr output from the driver process is simply piped to stderr of the parent process (where the test runs), so you should already be able to see all those errors as part of stderr.

'/private/var/folders/yc/h50n8fgn0h79y848sfkr942h0000gn/T/playwright-java-17403553361898517108/package/lib/cli/cli.js' was gone, for whatever reason

  • hint 1: this was a very long-running session

    • are these Unix tmp files?

Yes, this is how playwright works today. We first extract the driver in a temp directory and then run it from there. We may replace that with a step where we download the driver once during installation / first run.

  • hint 2: I ran node commands in this directory during this time

    • may a node invocation spoil playwright's node?

Playwright doesn't expect anyone else to touch the node modules / run any node commands in that directory. Even though merely running some node.js commands in that directory may be hamless, others may well modify the driver in an unexpected way.

yury-s avatar May 30 '23 16:05 yury-s

We can probably also include a few last stderr lines into the exception.

That would seem nice!

We may replace that with a step where we download the driver once during installation / first run.

Thanks for considering it.

Playwright doesn't expect anyone else to touch the node modules / run any node commands in that directory.

Sorry for the confusion, I had only run node in my project directory, not in the temp directory. I guess that no interference can happen then.

vemv avatar May 30 '23 17:05 vemv

Sorry for the confusion, I had only run node in my project directory, not in the temp directory. I guess that no interference can happen then.

Yes, this should not matter.

yury-s avatar May 30 '23 18:05 yury-s