fix(trace): keep client paths out of remote launch options - #42436
Conversation
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
A bit of a nitpick, but it seems like the options coming from the and the filtering function looking like this: playwright/packages/playwright-core/src/remote/playwrightServer.ts Lines 368 to 384 in 20e2f50 so the tracesDir was being filtered out anyway and artifactsDir was in fact allowed only when isUnsafe was being passed. And it is true that in my case where I had an error, I was launching the server with --usafe flag. My guess is that passing artifactsDir as a launch option is something used by the extension so it cannot be completely filtered out in there. Maybe the that filtering fn should make a distinction between "extension mode" and "--unsafe"? 🤔
|
|
Btw backporting just this small change to 1.62.1 also makes the |
| headers: { | ||
| // HTTP headers are ASCII only (not UTF-8). | ||
| 'x-playwright-launch-options': jsonStringifyForceASCII(_browserOptions), | ||
| 'x-playwright-launch-options': jsonStringifyForceASCII({ |
There was a problem hiding this comment.
Filters like this should be done on the server side. In fact, we already do something along these lines in packages/playwright-core/src/remote/playwrightServer.ts (see filterLaunchOptions) - why doesn't that work?
There was a problem hiding this comment.
See my earlier comment, it's because of the --unsafe flag. I need that flag but now it causes the artifactsDir to be passed from client to server, making server try to access path that might not exist there. But since it's probably used by the VSCode extension, it probably cannot be completely filtered out on server side. I think removing it on the client side is not wrong. What might be wrong is that the --unsafe flag is treated identically as "extension mode".
be4f626 to
190b7bd
Compare
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
Hi, I'm the Playwright bot and I took a look at the CI failures here. 🟢 The PR is clear — the one failure is a pre-existing Firefox flakeThe single red test, DetailsOverall: no failure is attributable to this PR. One real red, confirmed pre-existing flake; the rest is retry-rescued noise. Pre-existing flake / infra
Triaged by the Playwright bot - agent run |
|
Devin, what are we trying to fix here? I don't think passing |
|
Dmitry Gozman (@dgozman) Sorry this is not clear from the original issue, I discovered it's happening because of |
|
|
| executablePath: (isUnderTest() || allowUnsafe) ? options.executablePath : undefined, | ||
| downloadsPath: allowUnsafe ? options.downloadsPath : undefined, | ||
| artifactsDir: (isUnderTest() || allowUnsafe) ? options.artifactsDir : undefined, | ||
| artifactsDir: (isUnderTest() || isExtension) ? options.artifactsDir : undefined, |
There was a problem hiding this comment.
If we are splitting unsafe vs local-only, let's apply the same treatment to the downloadsPath.
remote servers started with `--unsafe` can use filesystem paths that only exist on the client allow client `artifactsDir` and `downloadsPath` only in extension mode
190b7bd to
30a6493
Compare
Test results for "tests 1"6 flaky51292 passed, 1241 skipped Merge workflow run. |
Test results for "MCP"8308 passed, 1377 skipped Merge workflow run. |
remote browser servers can receive Playwright Test worker paths and try to write trace files on the client filesystem
remove
artifactsDirandtracesDirfrom remote launch optionsfixes #42394