bug: Playwright driver download fails with 404 error during startup

[Kher0]

Description

When running the latest docker image, the scraper fails to start because it attempts to download a Playwright driver version (1.57.0) that is no longer available on the Azure CDN, resulting in a 404 Not Found error.

Error Logs

could not install driver: error: got non 200 status code: 404 (404 Not Found) from https://playwright.azureedge.net/builds/driver/playwright-1.57.0-linux.zip

Environment

• Docker Image: gosom/google-maps-scraper:latest
• OS: WSL2 (Ubuntu)

[xavier-villelegier]

Hey @gosom, this is failing for everyone because the driver was removed from the registry, a PR was opened here to fix it 🙏 #301

[santiagovittor]

Dug into this a bit further since #301 didn't unblock me. Two things worth flagging before someone merges it as-is.

#301 targets the wrong version. It bumps to v0.6000.0, but that tag was cut at 2026-06-26T01:33, roughly 15 hours before mxschmitt/playwright-go#615 merged (16:21 the same day). That PR is the actual fix: it drops the azureedge.net CDN dependency and assembles the driver from npm plus a Node.js binary from nodejs.org instead. So v0.6000.0 is still CDN-dependent. I confirmed this the hard way: built gosom off #301's branch, and playwright-1.60.0-linux.zip 404'd exactly like 1.57.0 does now. v0.6100.0 (tagged 20:18 the same day) is the first tag that actually contains the fix; I grepped that tag's run.go for registry.npmjs.org and nodejs.org, both present, azureedge gone entirely.

A go.mod bump alone won't be enough, even at the right version. gosom/scrapemate's adapters/fetchers/jshttp also imports github.com/playwright-community/playwright-go directly. go mod graph shows it as a second edge into the old path, separate from gosom's own runner/installplaywright. I tried routing around touching scrapemate with replace github.com/playwright-community/playwright-go => github.com/mxschmitt/playwright-go v0.6100.0 in gosom's go.mod. It fails deterministically with used for two different module paths, because the new module's own source (browser_context.go) imports its internal/safe subpackage by its real path, and Go's resolver won't let that coexist with a replace redirecting the old path at the same module. Reproduced identically three ways: manual go mod edit plus tidy, go get plus replace plus tidy, and an incremental -mod=mod build. Same error every time.

So this needs two coordinated changes, not one. scrapemate's jshttp fetcher needs to import github.com/mxschmitt/playwright-go directly, then gosom's go.mod can bump straight to v0.6100.0+ under that same path with no replace directive, since nothing would still be pointing at the old one. Happy to open both PRs if that's useful, just didn't want to duplicate work if someone's already on it.

[xavier-villelegier]

@santiagovittor Well https://playwright.azureedge.net/builds/driver/playwright-1.60.0-linux.zip was accessible when I opened the PR, it was working on my side 😕 I think you can open the PRs cause I didn't see any ongoing work on this.

[santiagovittor]

Thanks for the quick merge, and for the fast follow-up commit (25751bf, "Fixes 404 playwright") that switched the driver install over to mxschmitt/playwright-go. Tested it today against the freshly rebuilt latest on Docker Hub (its org.opencontainers.image.revision label matches 25751bf, pushed at 11:03 UTC, right after 25751bf landed).

Still 404s the same way as before:

error scraping job ...: could not install driver: could not install driver:
error: got non 200 status code: 404 (404 Not Found) from https://playwright.azureedge.net/builds/driver/playwright-1.57.0-linux.zip
error: got non 200 status code: 404 ... playwright-akamai.azureedge.net ...
error: got non 200 status code: 404 ... playwright-verizon.azureedge.net ...

Two things I found digging into why, both confirmed from source rather than guessed:

1. The fix touches one of two entry points that install the driver. installplaywright.go now imports mxschmitt/playwright-go, but that run mode only triggers when PLAYWRIGHT_INSTALL_ONLY=1 is set. A normal -web scrape job runs through gosom/scrapemate@v1.2.1's adapters/fetchers/jshttp/jshttp.go instead, which imports github.com/playwright-community/playwright-go directly and calls Install()/Run() on it itself. That file lives in scrapemate, not this repo, and neither #301 nor 25751bf touches it. This is the same scrapemate co-dependency I flagged in my last comment, still open.

2. Something odd with the published image, separate from point 1. I grepped the compiled binary for embedded module info (grep -aoE 'github.com/(mxschmitt|playwright-community)/playwright-go[[:space:]]v[0-9.]+' /usr/bin/google-maps-scraper inside the running container) and it has github.com/playwright-community/playwright-go v0.5700.1 baked in, the pre-#301 version. But go.mod and go.sum at 25751bf both only reference v0.6000.0 for that package, no v0.5700.1 checksum anywhere in go.sum. I don't know why that mismatch exists. Could be a stale Docker build-cache layer on the go mod download step that didn't invalidate when go.mod changed. Flagging it in case it's useful, not claiming to know the cause for sure.

Happy to open the scrapemate PR (swap jshttp.go to mxschmitt/playwright-go, then this repo's go.mod can drop the playwright-community indirect entry entirely) if that would help, since it doesn't look like anyone's picked it up yet.

[gosom]

Can you please check the latest version?

[santiagovittor]

Just checked, and there's real movement since the 13th, even though the image is labeled with the same 25751bf revision.

Two things got better. First, the stale-binary mismatch I flagged last time is gone: I grepped /usr/bin/google-maps-scraper inside a freshly pulled, force-recreated container, and it now reports playwright-community/playwright-go v0.6000.0 cleanly, no more leftover v0.5700.1. Second, the Docker build itself now bakes a working driver into the image through installplaywright.go's mxschmitt path — /opt/ms-playwright-go/package/package.json inside the container reports playwright-core 1.61.1, timestamped to the image build, no CDN call involved.

The job still fails immediately, though, just with a different error now: could not install driver: could not install driver: driver exists but version not 1.60.0 in : /opt/ms-playwright-go. That's scrapemate's jshttp fetcher, still on playwright-community v0.6000.0, which is hardcoded to expect driver 1.60.0. It finds 1.61.1 already sitting there from the other install path and refuses to touch it. Two packages, two expected versions, one driver directory — same co-dependency as before, just surfacing as a version check instead of a 404 now that the build-time install actually works.

Which is why #25 on scrapemate (gosom/scrapemate#25) is still the piece that closes this: it moves the jshttp fetcher onto mxschmitt too, so both install paths agree on one package and one version instead of stepping on each other. It's been open a few days with no review yet — happy to adjust anything on it or split it up if that makes it easier to land.

[florisdipt]

Just checked, and there's real movement since the 13th, even though the image is labeled with the same 25751bf revision.

Two things got better. First, the stale-binary mismatch I flagged last time is gone: I grepped /usr/bin/google-maps-scraper inside a freshly pulled, force-recreated container, and it now reports playwright-community/playwright-go v0.6000.0 cleanly, no more leftover v0.5700.1. Second, the Docker build itself now bakes a working driver into the image through installplaywright.go's mxschmitt path — /opt/ms-playwright-go/package/package.json inside the container reports playwright-core 1.61.1, timestamped to the image build, no CDN call involved.

The job still fails immediately, though, just with a different error now: could not install driver: could not install driver: driver exists but version not 1.60.0 in : /opt/ms-playwright-go. That's scrapemate's jshttp fetcher, still on playwright-community v0.6000.0, which is hardcoded to expect driver 1.60.0. It finds 1.61.1 already sitting there from the other install path and refuses to touch it. Two packages, two expected versions, one driver directory — same co-dependency as before, just surfacing as a version check instead of a 404 now that the build-time install actually works.

Which is why #25 on scrapemate (gosom/scrapemate#25) is still the piece that closes this: it moves the jshttp fetcher onto mxschmitt too, so both install paths agree on one package and one version instead of stepping on each other. It's been open a few days with no review yet — happy to adjust anything on it or split it up if that makes it easier to land.

Confirmed, this matches our production test. @gosom please merge and release scrapemate#25, then bump it in google-maps-scraper and publish a new image; that should make the upstream image usable again.

Until then, we rebuilt v1.16.3 privately with Scrapemate pinned to the #25 commit so both runtime paths use the same Playwright driver.

[harmsluis]

Confirmed on Linux ARM64 (Oracle Cloud, aarch64) using google-maps-scraper v1.16.3, built locally from source.

The image builds successfully and installs Playwright/Chromium 1.61.1 for ARM64. The server starts and responds with HTTP 200, but every web job fails through Scrapemate with:

could not install driver:
404 Not Found
https://playwright.azureedge.net/builds/driver/playwright-1.60.0-linux-arm64.zip

The dependency graph contains both:

github.com/mxschmitt/playwright-go v0.6100.0
github.com/playwright-community/playwright-go v0.6000.0

This confirms that the problem also affects native ARM64 builds. Playwright and Chromium themselves work on ARM64; the failure is specifically caused by Scrapemate requesting the unavailable 1.60.0 ARM64 driver.

gosom/scrapemate#25 appears to be the correct fix. After merging it, Scrapemate needs a new release, followed by a dependency bump and rebuilt Docker image in google-maps-scraper.

[Krunal-Karena]

facing same issue.

[iSerter]

With v1.16.3, I get

2026/07/21 11:25:13 error scraping job 9a756868-a8e1-482b-883a-596b477a0009: could not install driver: could not install driver: driver exists but version not 1.60.0 in : /opt/ms-playwright-go

gosom/scrapemate#25 looks like a good fix. that playwright-community/playwright-go repo has been renamed as mxschmitt/playwright-go.

@gosom

[gosom]

https://github.com/gosom/google-maps-scraper/releases/tag/v1.17.1