[GH-ISSUE #134] Intermittent network response dropping when building and executing inside docker

kerem commented

2026-03-01 14:40:31 +03:00

Owner

Originally created by @mawmawmawm on GitHub (Jan 25, 2019).
Original GitHub issue: https://github.com/ArchiveBox/ArchiveBox/issues/134

It seems like the pocket RSS feeds are not being parsed correctly and fragments of the XML / HTML tags are being included in the links.
Here's how to reproduce this:

docker-compose exec archivebox /bin/archive http://getpocket.com/users/*[redacted]/feed/all

I created a pocket-account with two links in it, the corresponding RSS that is being downloaded looks like this:

<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
    xmlns:content="http://purl.org/rss/1.0/modules/content/"
    xmlns:wfw="http://wellformedweb.org/CommentAPI/"
    xmlns:dc="http://purl.org/dc/elements/1.1/"
    xmlns:atom="http://www.w3.org/2005/Atom"
    >

<channel>

<title>My Reading List: Read and Unread</title>
<description>Items I've saved to read</description>
<link>http://readitlaterlist.com/users/*[redacted]/feed/all</link>
<atom:link href="http://readitlaterlist.com/users/*[redacted]/feed/all" rel="self" type="application/rss+xml" />


<item>
<title><![CDATA[Trump Agrees to Reopen Government for 3 Weeks in Surprise Retreat From Wall]]></title>
<category>Unread</category>
<link>https://nytimes.com/2019/01/25/us/politics/trump-shutdown-deal.html</link>
<guid>https://nytimes.com/2019/01/25/us/politics/trump-shutdown-deal.html</guid>
<pubDate>Fri, 25 Jan 2019 16:21:38 -0600</pubDate>
</item>
<item>
<title><![CDATA[Neue Passwort-Leaks: Insgesamt 2,2 Milliarden Accounts betroffen]]></title>
<category>Unread</category>
<link>https://heise.de/security/meldung/Neue-Passwort-Leaks-Insgesamt-2-2-Milliarden-Accounts-betroffen-4287538.html</link>
<guid>https://heise.de/security/meldung/Neue-Passwort-Leaks-Insgesamt-2-2-Milliarden-Accounts-betroffen-4287538.html</guid>
<pubDate>Fri, 25 Jan 2019 16:20:07 -0600</pubDate>
</item>
</channel>

</rss>

Instead of the two <link> s, the software now tries to pull in 10 links and seems to mess up the URLs:

[▶] [2019-01-25 22:30:05] Updating files for 10 links in archive...
[+] [2019-01-25 22:30:09] "https://heise.de/security/meldung/Neue-Passwort-Leaks-Insgesamt-2-2-Milliarden-Accounts-betroffen-4287538.html</guid>"
    https://heise.de/security/meldung/Neue-Passwort-Leaks-Insgesamt-2-2-Milliarden-Accounts-betroffen-4287538.html</guid>
    > /data/archive/1548455383 (new)
      > favicon
      > wget
        Got wget response code 8:
          https://www.heise.de/security/meldung/Neue-Passwort-Leaks-Insgesamt-2-2-Milliarden-Accounts-betroffen-4287538.html%3c/guid%3e:
          2019-01-25 22:30:12 ERROR 404: Not Found.
        Some resources were skipped: 404 Not Found
        Run to see full output:
            cd /data/archive/1548455383;
            wget --no-verbose --adjust-extension --convert-links --force-directories --backup-converted --span-hosts --no-parent --restrict-file-names=unix --timeout=60 --warc-file=warc/1548455410 --page-requisites --user-agent="ArchiveBox/544de6831 (+https://github.com/pirate/ArchiveBox/) wget/1.18" https://heise.de/security/meldung/Neue-Passwort-Leaks-Insgesamt-2-2-Milliarden-Accounts-betroffen-4287538.html</guid>
      > pdf
      > screenshot
      > dom
      > archive_org
        Failed: Exception BadQueryException: Illegal character in path at index 110: https://heise.de/security/meldung/Neue-Passwort-Leaks-Insgesamt-2-2-Milliarden-Accounts-betroffen-4287538.html</guid>
        Run to see full output:
            curl --location --head --max-time 60 --get https://web.archive.org/save/https://heise.de/security/meldung/Neue-Passwort-Leaks-Insgesamt-2-2-Milliarden-Accounts-betroffen-4287538.html</guid>
      > git
      √ index.json
      √ index.html

(note the <guid> at the end of the URL wget is trying to download.

In the end, no links could be saved:

[√] [2019-01-25 22:35:50] Update of 10 links complete (5.75 min)
    - 10 entries skipped
    - 44 entries updated
    - 16 errors

Latest stable version.

Originally created by @mawmawmawm on GitHub (Jan 25, 2019). Original GitHub issue: https://github.com/ArchiveBox/ArchiveBox/issues/134 It seems like the pocket RSS feeds are not being parsed correctly and fragments of the XML / HTML tags are being included in the links. Here's how to reproduce this: ``` docker-compose exec archivebox /bin/archive http://getpocket.com/users/*[redacted]/feed/all ``` I created a pocket-account with two links in it, the corresponding RSS that is being downloaded looks like this: ``` <?xml version="1.0" encoding="UTF-8"?><rss version="2.0" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:wfw="http://wellformedweb.org/CommentAPI/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:atom="http://www.w3.org/2005/Atom" > <channel> <title>My Reading List: Read and Unread</title> <description>Items I've saved to read</description> <link>http://readitlaterlist.com/users/*[redacted]/feed/all</link> <atom:link href="http://readitlaterlist.com/users/*[redacted]/feed/all" rel="self" type="application/rss+xml" /> <item> <title><![CDATA[Trump Agrees to Reopen Government for 3 Weeks in Surprise Retreat From Wall]]></title> <category>Unread</category> <link>https://nytimes.com/2019/01/25/us/politics/trump-shutdown-deal.html</link> <guid>https://nytimes.com/2019/01/25/us/politics/trump-shutdown-deal.html</guid> <pubDate>Fri, 25 Jan 2019 16:21:38 -0600</pubDate> </item> <item> <title><![CDATA[Neue Passwort-Leaks: Insgesamt 2,2 Milliarden Accounts betroffen]]></title> <category>Unread</category> <link>https://heise.de/security/meldung/Neue-Passwort-Leaks-Insgesamt-2-2-Milliarden-Accounts-betroffen-4287538.html</link> <guid>https://heise.de/security/meldung/Neue-Passwort-Leaks-Insgesamt-2-2-Milliarden-Accounts-betroffen-4287538.html</guid> <pubDate>Fri, 25 Jan 2019 16:20:07 -0600</pubDate> </item> </channel> </rss> ``` Instead of the two `<link>` s, the software now tries to pull in 10 links and seems to mess up the URLs: ``` [▶] [2019-01-25 22:30:05] Updating files for 10 links in archive... [+] [2019-01-25 22:30:09] "https://heise.de/security/meldung/Neue-Passwort-Leaks-Insgesamt-2-2-Milliarden-Accounts-betroffen-4287538.html</guid>" https://heise.de/security/meldung/Neue-Passwort-Leaks-Insgesamt-2-2-Milliarden-Accounts-betroffen-4287538.html</guid> > /data/archive/1548455383 (new) > favicon > wget Got wget response code 8: https://www.heise.de/security/meldung/Neue-Passwort-Leaks-Insgesamt-2-2-Milliarden-Accounts-betroffen-4287538.html%3c/guid%3e: 2019-01-25 22:30:12 ERROR 404: Not Found. Some resources were skipped: 404 Not Found Run to see full output: cd /data/archive/1548455383; wget --no-verbose --adjust-extension --convert-links --force-directories --backup-converted --span-hosts --no-parent --restrict-file-names=unix --timeout=60 --warc-file=warc/1548455410 --page-requisites --user-agent="ArchiveBox/544de6831 (+https://github.com/pirate/ArchiveBox/) wget/1.18" https://heise.de/security/meldung/Neue-Passwort-Leaks-Insgesamt-2-2-Milliarden-Accounts-betroffen-4287538.html</guid> > pdf > screenshot > dom > archive_org Failed: Exception BadQueryException: Illegal character in path at index 110: https://heise.de/security/meldung/Neue-Passwort-Leaks-Insgesamt-2-2-Milliarden-Accounts-betroffen-4287538.html</guid> Run to see full output: curl --location --head --max-time 60 --get https://web.archive.org/save/https://heise.de/security/meldung/Neue-Passwort-Leaks-Insgesamt-2-2-Milliarden-Accounts-betroffen-4287538.html</guid> > git √ index.json √ index.html ``` (note the `<guid>` at the end of the URL wget is trying to download. In the end, no links could be saved: ``` [√] [2019-01-25 22:35:50] Update of 10 links complete (5.75 min) - 10 entries skipped - 44 entries updated - 16 errors ``` Latest stable version.

kerem closed this issue

2026-03-01 14:40:31 +03:00

kerem commented

2026-03-01 14:40:32 +03:00

Author

Owner

@pirate commented on GitHub (Jan 26, 2019):

What a coincidence, I just ran into this myself 20min ago, not sure what broke but I'll take a look.

@pirate commented on GitHub (Jan 26, 2019): What a coincidence, I just ran into this myself 20min ago, not sure what broke but I'll take a look.

kerem commented

2026-03-01 14:40:32 +03:00

Author

Owner

@pirate commented on GitHub (Jan 26, 2019):

Can you give this a shot: ff125d9 (latest master)

Hope I didn't mess up your archive, it might be a pain but you should be able to use https://github.com/pirate/ArchiveBox/blob/master/archivebox/purge.py to remove any bad links.

@pirate commented on GitHub (Jan 26, 2019): Can you give this a shot: ff125d9 (latest master) Hope I didn't mess up your archive, it might be a pain but you should be able to use https://github.com/pirate/ArchiveBox/blob/master/archivebox/purge.py to remove any bad links.

kerem commented

2026-03-01 14:40:32 +03:00

Author

Owner

@mawmawmawm commented on GitHub (Jan 26, 2019):

Hey, I’d love to try it, but I’m running into the same old error again that I mentioned in my other ticket. In the mean time it worked however. Could this be a server issue on Googles side of things?
I tried to delete everything and rebuilt everything at least 5 times with no cache, but no luck. Errors out on different lines / chars btw.

... 
Step 7/15 : RUN npm i puppeteer
 ---> Running in 247562d29cdd
npm ERR! Unexpected end of JSON input while parsing near '...imraf":"^2.6.1","ws":'

npm ERR! A complete log of this run can be found in:
npm ERR!     /root/.npm/_logs/2019-01-26T07_08_12_431Z-debug.log
Removing intermediate container 247562d29cdd
ERROR: Service 'archivebox' failed to build: The command '/bin/sh -c npm i puppeteer' returned a non-zero code: 1

@mawmawmawm commented on GitHub (Jan 26, 2019): Hey, I’d love to try it, but I’m running into the same old error again that I mentioned in my other ticket. In the mean time it worked however. Could this be a server issue on Googles side of things? I tried to delete everything and rebuilt everything at least 5 times with no cache, but no luck. Errors out on different lines / chars btw. ``` ... Step 7/15 : RUN npm i puppeteer ---> Running in 247562d29cdd npm ERR! Unexpected end of JSON input while parsing near '...imraf":"^2.6.1","ws":' npm ERR! A complete log of this run can be found in: npm ERR! /root/.npm/_logs/2019-01-26T07_08_12_431Z-debug.log Removing intermediate container 247562d29cdd ERROR: Service 'archivebox' failed to build: The command '/bin/sh -c npm i puppeteer' returned a non-zero code: 1 ```

kerem commented

2026-03-01 14:40:32 +03:00

Author

Owner

@mawmawmawm commented on GitHub (Jan 26, 2019):

I tried a couple things, e.g. update npm via npm i npm (Now npm@5.6.0 /usr/local/lib/node_modules/npm) and also npm cache clean --force as well as npm update
but I’m still running into the same issue.

docker-compose build --no-cache --force-rm also didn’t help.
Other sites mention this would be due to an invalid npm coaching mechanism in older versions, any idea how to fix this?

@mawmawmawm commented on GitHub (Jan 26, 2019): I tried a couple things, e.g. update npm via `npm i npm` (Now `npm@5.6.0 /usr/local/lib/node_modules/npm`) and also `npm cache clean --force` as well as `npm update` but I’m still running into the same issue. ` docker-compose build --no-cache --force-rm` also didn’t help. Other sites mention this would be due to an invalid npm coaching mechanism in older versions, any idea how to fix this?

kerem commented

2026-03-01 14:40:32 +03:00

Author

Owner

@pirate commented on GitHub (Jan 26, 2019):

It's very odd because I cant reproduce it, and it's happening during the build process which should theoretically be the same no matter what machine you're building on.

Try pulling the latest master, I bumped the base image version up from 8 to 11.

@pirate commented on GitHub (Jan 26, 2019): It's very odd because I cant reproduce it, and it's happening during the build process which should theoretically be the same no matter what machine you're building on. Try pulling the latest master, I bumped the base image version up from `8` to `11`.

kerem commented

2026-03-01 14:40:32 +03:00

Author

Owner

@mawmawmawm commented on GitHub (Jan 27, 2019):

Thanks for your quick response, but no luck - I'm sorry.
I tried everything I could think of...

Removing all the old images via docker rmi <id> and also the old containers
NPM update etc as described above
checked out new master with node11 (confirmed)
tried docker-compose build --no-cache --force-rm (which takes considerably longer since everything is done from scratch again)

But no luck. Still the same issue in step 7/15 with ...

Step 7/15 : RUN npm i puppeteer
 ---> Running in d2a68dc52935
npm ERR! Unexpected end of JSON input while parsing near '...st":{"shasum":"76ec7d'

npm ERR! A complete log of this run can be found in:
npm ERR!     /root/.npm/_logs/2019-01-27T04_30_51_307Z-debug.log
Removing intermediate container d2a68dc52935
ERROR: Service 'archivebox' failed to build: The command '/bin/sh -c npm i puppeteer' returned a non-zero code: 1

As mentioned, the actual "end" varies and the while parsing near... is always different.
I don't know why it worked once (basically before I created this issue) and now not anymore...

@mawmawmawm commented on GitHub (Jan 27, 2019): Thanks for your quick response, but no luck - I'm sorry. I tried everything I could think of... - Removing all the old images via `docker rmi <id>` and also the old containers - NPM update etc as described above - checked out new master with node11 (confirmed) - tried `docker-compose build --no-cache --force-rm` (which takes considerably longer since everything is done from scratch again) But no luck. Still the same issue in step 7/15 with ... ``` Step 7/15 : RUN npm i puppeteer ---> Running in d2a68dc52935 npm ERR! Unexpected end of JSON input while parsing near '...st":{"shasum":"76ec7d' npm ERR! A complete log of this run can be found in: npm ERR! /root/.npm/_logs/2019-01-27T04_30_51_307Z-debug.log Removing intermediate container d2a68dc52935 ERROR: Service 'archivebox' failed to build: The command '/bin/sh -c npm i puppeteer' returned a non-zero code: 1 ``` As mentioned, the actual "end" varies and the _while parsing near_... is always different. I don't know why it worked once (basically before I created this issue) and now not anymore...

kerem commented

2026-03-01 14:40:32 +03:00

Author

Owner

@mawmawmawm commented on GitHub (Jan 28, 2019):

OK, I did more digging. I edited the Dockerfile to include an RUN npm cache clean --force before the puppeteer (now step 8 instead of 7) installation, but no luck there as well:


 ---> 73357b1217dc
Removing intermediate container 84e268fc0b12
Step 6/16 : RUN chmod +x /usr/local/bin/dumb-init
 ---> Running in bd8430cbfbf9
 ---> dcaaf479c297
Removing intermediate container bd8430cbfbf9
Step 7/16 : RUN npm cache clean --force
 ---> Running in 7d6f8353ba49
npm WARN using --force I sure hope you know what you are doing.
 ---> 22fe375cd41a
Removing intermediate container 7d6f8353ba49
Step 8/16 : RUN npm i puppeteer
 ---> Running in 8a5d51af5bac
npm ERR! Unexpected end of JSON input while parsing near '...s/extract-zip":"^1.6.'

npm ERR! A complete log of this run can be found in:
npm ERR!     /root/.npm/_logs/2019-01-28T04_26_16_469Z-debug.log

I then reduced the Dockerfile to the bare minimum to see if that would give me any clue:

FROM node:11-slim
LABEL maintainer="Nick Sweeting <archivebox-git@sweeting.me>"

# RUN apt-get update \
#    && apt-get install -yq --no-install-recommends \
#        git wget curl youtube-dl gnupg2 libgconf-2-4 python3 python3-pip \
#    && rm -rf /var/lib/apt/lists/*

# Install latest chrome package and fonts to support major charsets (Chinese, Japanese, Arabic, Hebrew, Thai and a few others)
RUN apt-get update && apt-get install -y wget --no-install-recommends \
    && wget -q -O - https://dl-ssl.google.com/linux/linux_signing_key.pub | apt-key add - \
    && sh -c 'echo "deb [arch=amd64] http://dl.google.com/linux/chrome/deb/ stable main" >> /etc/apt/sources.list.d/google.list' \
    && apt-get update \
    && apt-get install -y google-chrome-unstable fonts-ipafont-gothic fonts-wqy-zenhei fonts-thai-tlwg fonts-kacst ttf-freefont \
      --no-install-recommends \
    && rm -rf /var/lib/apt/lists/* \
    && rm -rf /src/*.deb

# It's a good idea to use dumb-init to help prevent zombie chrome processes.
#ADD https://github.com/Yelp/dumb-init/releases/download/v1.2.0/dumb-init_1.2.0_amd64 /usr/local/bin/dumb-init
#RUN chmod +x /usr/local/bin/dumb-init

# Do a npm clean
#RUN npm cache clean --force

# Install puppeteer so it's available in the container.
RUN npm i puppeteer

# Add user so we don't need --no-sandbox.
#RUN groupadd -r pptruser && useradd -r -g pptruser -G audio,video pptruser \
#    && mkdir -p /home/pptruser/Downloads \
#    && chown -R pptruser:pptruser /home/pptruser \
#    && chown -R pptruser:pptruser /node_modules

# Install the ArchiveBox repository and pip requirements
#RUN git clone https://github.com/pirate/ArchiveBox /home/pptruser/app \
#    && mkdir -p /data \
#    && chown -R pptruser:pptruser /data \
#    && ln -s /data /home/pptruser/app/archivebox/output \
#    && ln -s /home/pptruser/app/bin/archivebox /bin/archive \
#    && chown -R pptruser:pptruser /home/pptruser/app/archivebox
#    # && pip3 install -r /home/pptruser/app/archivebox/requirements.txt

VOLUME /data

ENV LANG=C.UTF-8 \
    LANGUAGE=en_US:en \
    LC_ALL=C.UTF-8 \
    PYTHONIOENCODING=UTF-8 \
    CHROME_SANDBOX=False \

But still (this time errored out on the same spot):

Step 4/10 : RUN npm i puppeteer
 ---> Running in cdcae8339d94
npm ERR! Unexpected end of JSON input while parsing near '...s/extract-zip":"^1.6.'

npm ERR! A complete log of this run can be found in:
npm ERR!     /root/.npm/_logs/2019-01-28T04_35_30_363Z-debug.log
ERROR: Service 'archivebox' failed to build: The command '/bin/sh -c npm i puppeteer' returned a non-zero code: 1

So the error must be within the npm package of puppeteer?!

@mawmawmawm commented on GitHub (Jan 28, 2019): OK, I did more digging. I edited the `Dockerfile` to include an `RUN npm cache clean --force` before the puppeteer (now step 8 instead of 7) installation, but no luck there as well: ``` ---> 73357b1217dc Removing intermediate container 84e268fc0b12 Step 6/16 : RUN chmod +x /usr/local/bin/dumb-init ---> Running in bd8430cbfbf9 ---> dcaaf479c297 Removing intermediate container bd8430cbfbf9 Step 7/16 : RUN npm cache clean --force ---> Running in 7d6f8353ba49 npm WARN using --force I sure hope you know what you are doing. ---> 22fe375cd41a Removing intermediate container 7d6f8353ba49 Step 8/16 : RUN npm i puppeteer ---> Running in 8a5d51af5bac npm ERR! Unexpected end of JSON input while parsing near '...s/extract-zip":"^1.6.' npm ERR! A complete log of this run can be found in: npm ERR! /root/.npm/_logs/2019-01-28T04_26_16_469Z-debug.log ``` I then reduced the Dockerfile to the bare minimum to see if that would give me any clue: ``` FROM node:11-slim LABEL maintainer="Nick Sweeting <archivebox-git@sweeting.me>" # RUN apt-get update \ # && apt-get install -yq --no-install-recommends \ # git wget curl youtube-dl gnupg2 libgconf-2-4 python3 python3-pip \ # && rm -rf /var/lib/apt/lists/* # Install latest chrome package and fonts to support major charsets (Chinese, Japanese, Arabic, Hebrew, Thai and a few others) RUN apt-get update && apt-get install -y wget --no-install-recommends \ && wget -q -O - https://dl-ssl.google.com/linux/linux_signing_key.pub | apt-key add - \ && sh -c 'echo "deb [arch=amd64] http://dl.google.com/linux/chrome/deb/ stable main" >> /etc/apt/sources.list.d/google.list' \ && apt-get update \ && apt-get install -y google-chrome-unstable fonts-ipafont-gothic fonts-wqy-zenhei fonts-thai-tlwg fonts-kacst ttf-freefont \ --no-install-recommends \ && rm -rf /var/lib/apt/lists/* \ && rm -rf /src/*.deb # It's a good idea to use dumb-init to help prevent zombie chrome processes. #ADD https://github.com/Yelp/dumb-init/releases/download/v1.2.0/dumb-init_1.2.0_amd64 /usr/local/bin/dumb-init #RUN chmod +x /usr/local/bin/dumb-init # Do a npm clean #RUN npm cache clean --force # Install puppeteer so it's available in the container. RUN npm i puppeteer # Add user so we don't need --no-sandbox. #RUN groupadd -r pptruser && useradd -r -g pptruser -G audio,video pptruser \ # && mkdir -p /home/pptruser/Downloads \ # && chown -R pptruser:pptruser /home/pptruser \ # && chown -R pptruser:pptruser /node_modules # Install the ArchiveBox repository and pip requirements #RUN git clone https://github.com/pirate/ArchiveBox /home/pptruser/app \ # && mkdir -p /data \ # && chown -R pptruser:pptruser /data \ # && ln -s /data /home/pptruser/app/archivebox/output \ # && ln -s /home/pptruser/app/bin/archivebox /bin/archive \ # && chown -R pptruser:pptruser /home/pptruser/app/archivebox # # && pip3 install -r /home/pptruser/app/archivebox/requirements.txt VOLUME /data ENV LANG=C.UTF-8 \ LANGUAGE=en_US:en \ LC_ALL=C.UTF-8 \ PYTHONIOENCODING=UTF-8 \ CHROME_SANDBOX=False \ ``` But still (this time errored out on the same spot): ``` Step 4/10 : RUN npm i puppeteer ---> Running in cdcae8339d94 npm ERR! Unexpected end of JSON input while parsing near '...s/extract-zip":"^1.6.' npm ERR! A complete log of this run can be found in: npm ERR! /root/.npm/_logs/2019-01-28T04_35_30_363Z-debug.log ERROR: Service 'archivebox' failed to build: The command '/bin/sh -c npm i puppeteer' returned a non-zero code: 1 ``` So the error must be within the npm package of puppeteer?!

kerem commented

2026-03-01 14:40:32 +03:00

Author

Owner

@mawmawmawm commented on GitHub (Jan 28, 2019):

So... even more...
I changed puppeteer for puppeteer-core (a version of Puppeteer that doesn't download Chromium by default) in the Dockerfile, because we're installing chromium anyways separately. This at first failed as well:

Step 7/15 : RUN npm i puppeteer-core
 ---> Running in 4cfe4c562904
npm ERR! code EPROTO
npm ERR! errno EPROTO
npm ERR! request to https://registry.npmjs.org/rimraf failed, reason: write EPROTO 139977009982336:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure:../deps/openssl/openssl/ssl/record/rec_layer_s3.c:1407:SSL alert number 40
npm ERR!

npm ERR! A complete log of this run can be found in:
npm ERR!     /root/.npm/_logs/2019-01-28T05_08_25_248Z-debug.log
ERROR: Service 'archivebox' failed to build: The command '/bin/sh -c npm i puppeteer-core' returned a non-zero code: 1

There seems to be something going on either with my network connection or the npm servers.
I tried again:

Step 7/15 : RUN npm i puppeteer-core
 ---> Running in e1b3a79eaf9c
npm WARN tarball tarball data for es6-promise@^4.0.3 (sha512-n6wvpdE43VFtJq+lUDYDBFUwV8TZbuGXLV4D6wKafg13ldznKsyEvatubnmUe31zcvelSzOHF+XbaT+Bl9ObDg==) seems to be corrupted. Trying one more time.
npm WARN tarball tarball data for puppeteer-core@latest (sha512-JTsJKCQdrk1RqEGZN3l2TyW7Rhy7GWRRzd3PftYyA3B35l0t0lLU+gdF7czemnpSVVMiAgHpM1Uk/iO6jLreMA==) seems to be corrupted. Trying one more time.

> puppeteer-core@1.11.0 install /node_modules/puppeteer-core
> node install.js

npm WARN saveError ENOENT: no such file or directory, open '/package.json'
npm notice created a lockfile as package-lock.json. You should commit this file.
npm WARN enoent ENOENT: no such file or directory, open '/package.json'
npm WARN !invalid#1 No description
npm WARN !invalid#1 No repository field.
npm WARN !invalid#1 No README data
npm WARN !invalid#1 No license field.

+ puppeteer-core@1.11.0
added 43 packages from 22 contributors and audited 50 packages in 14.773s
found 0 vulnerabilities

 ---> 7538b1c16fbc

This finally did work. Not sure about the tarball errors.

Back to the original purpose of the ticket, pocket feeds not being properly imported: I tried the same RSS feed and this time my two links were parsed / downloaded correctly; screenshot, html, pdf confirmed and working.

Thanks again for your support and this project. Love it and i think it's very important. You might want to consider puppeteer-core .

@mawmawmawm commented on GitHub (Jan 28, 2019): So... even more... I changed `puppeteer` for `puppeteer-core` (a version of Puppeteer that doesn't download Chromium by default) in the Dockerfile, because we're installing chromium anyways separately. This at first failed as well: ``` Step 7/15 : RUN npm i puppeteer-core ---> Running in 4cfe4c562904 npm ERR! code EPROTO npm ERR! errno EPROTO npm ERR! request to https://registry.npmjs.org/rimraf failed, reason: write EPROTO 139977009982336:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure:../deps/openssl/openssl/ssl/record/rec_layer_s3.c:1407:SSL alert number 40 npm ERR! npm ERR! A complete log of this run can be found in: npm ERR! /root/.npm/_logs/2019-01-28T05_08_25_248Z-debug.log ERROR: Service 'archivebox' failed to build: The command '/bin/sh -c npm i puppeteer-core' returned a non-zero code: 1 ``` There seems to be something going on either with my network connection or the npm servers. I tried again: ``` Step 7/15 : RUN npm i puppeteer-core ---> Running in e1b3a79eaf9c npm WARN tarball tarball data for es6-promise@^4.0.3 (sha512-n6wvpdE43VFtJq+lUDYDBFUwV8TZbuGXLV4D6wKafg13ldznKsyEvatubnmUe31zcvelSzOHF+XbaT+Bl9ObDg==) seems to be corrupted. Trying one more time. npm WARN tarball tarball data for puppeteer-core@latest (sha512-JTsJKCQdrk1RqEGZN3l2TyW7Rhy7GWRRzd3PftYyA3B35l0t0lLU+gdF7czemnpSVVMiAgHpM1Uk/iO6jLreMA==) seems to be corrupted. Trying one more time. > puppeteer-core@1.11.0 install /node_modules/puppeteer-core > node install.js npm WARN saveError ENOENT: no such file or directory, open '/package.json' npm notice created a lockfile as package-lock.json. You should commit this file. npm WARN enoent ENOENT: no such file or directory, open '/package.json' npm WARN !invalid#1 No description npm WARN !invalid#1 No repository field. npm WARN !invalid#1 No README data npm WARN !invalid#1 No license field. + puppeteer-core@1.11.0 added 43 packages from 22 contributors and audited 50 packages in 14.773s found 0 vulnerabilities ---> 7538b1c16fbc ``` This finally did work. Not sure about the tarball errors. Back to the original purpose of the ticket, pocket feeds not being properly imported: I tried the same RSS feed and this time my two links were parsed / downloaded correctly; screenshot, html, pdf confirmed and working. Thanks again for your support and this project. Love it and i think it's very important. You might want to consider `puppeteer-core` .

kerem commented

2026-03-01 14:40:33 +03:00

Author

Owner

@pirate commented on GitHub (Jan 28, 2019):

I suspect the network error might actually still be happening, but that by reducing the number of requests needed to install it managed to succeed once?

Because it seems like a lower level network issue, if you want you could try testing curl https://registry.npmjs.org/rimraf inside the built container via exec, or by putting it somewhere in the Dockerfile then checking the output isn't truncated.

Is the working build reproducible for you? (does it succeed reliably multiple times when doing a --no-cache --force-rm rebuild)

If puppeteer-core does fix it reliably, then I'm happy to change to it, especially as you mentioned we're already installing chrome manually.

@pirate commented on GitHub (Jan 28, 2019): I suspect the network error might actually still be happening, but that by reducing the number of requests needed to install it managed to succeed once? Because it seems like a lower level network issue, if you want you could try testing `curl https://registry.npmjs.org/rimraf` inside the built container via `exec`, or by putting it somewhere in the Dockerfile then checking the output isn't truncated. Is the working build reproducible for you? (does it succeed reliably multiple times when doing a `--no-cache --force-rm` rebuild) If puppeteer-core does fix it reliably, then I'm happy to change to it, especially as you mentioned we're already installing chrome manually.

kerem commented

2026-03-01 14:40:33 +03:00

Author

Owner

@mawmawmawm commented on GitHub (Jan 28, 2019):

Looks like something with this server is weird. I tried this in the container:

$ wget https://registry.npmjs.org/rimraf                                                                                                                                        
--2019-01-28 17:30:09--  https://registry.npmjs.org/rimraf                                                                                                                      
Resolving registry.npmjs.org (registry.npmjs.org)... 104.16.18.35, 104.16.17.35, 104.16.16.35, ...                                                                              
Connecting to registry.npmjs.org (registry.npmjs.org)|104.16.18.35|:443... connected.                                                                                           
HTTP request sent, awaiting response... 200 OK                                                                                                                                  
Length: 63374 (62K) [application/json]                                                                                                                                          
Saving to: ‘rimraf’                                                                                                                                                             
                                                                                                                                                                                
rimraf               71%[=============>      ]  44.03K  --.-KB/s    in 0.005s                                                                                                   
                                                                                                                                                                                
2019-01-28 17:30:09 (8.87 MB/s) - Read error at byte 45089/63374 (Error in the pull function.). Retrying.                                                                       
                                                                                                                                                                                
--2019-01-28 17:30:10--  (try: 2)  https://registry.npmjs.org/rimraf                                                                                                            
Connecting to registry.npmjs.org (registry.npmjs.org)|104.16.18.35|:443... connected.                                                                                           
HTTP request sent, awaiting response... 206 Partial Content                                                                                                                     
Length: 63374 (62K), 18285 (18K) remaining [application/json]                                                                                                                   
Saving to: ‘rimraf’                                                                                                                                                             
                                                                                                                                                                                
rimraf              100%[++++++++++++++=====>]  61.89K  --.-KB/s    in 0.003s                                                                                                   
                                                                                                                                                                                
2019-01-28 17:30:10 (6.00 MB/s) - ‘rimraf’ saved [63374/63374]

Another try:

$ wget https://registry.npmjs.org/rimraf                                                                                                                                        
--2019-01-28 17:30:51--  https://registry.npmjs.org/rimraf                                                                                                                      
Resolving registry.npmjs.org (registry.npmjs.org)... 104.16.19.35, 104.16.18.35, 104.16.17.35, ...                                                                              
Connecting to registry.npmjs.org (registry.npmjs.org)|104.16.19.35|:443... connected.                                                                                           
HTTP request sent, awaiting response... 200 OK                                                                                                                                  
Length: 63374 (62K) [application/json]                                                                                                                                          
Saving to: ‘rimraf.1’                                                                                                                                                           
                                                                                                                                                                                
rimraf.1            100%[===================>]  61.89K  --.-KB/s    in 0.02s                                                                                                    
                                                                                                                                                                                
2019-01-28 17:30:51 (3.79 MB/s) - ‘rimraf.1’ saved [63374/63374]

Now I got the file on the first try, but the first time around not, see the Read error. wget then was smart enough to fetch the rest of the file (http 206, I diff'd the files and they're the same) but I don't know if npm is doing the same thing (since a http 200 was sent). If not, that explains the weird behavior I believe.

@mawmawmawm commented on GitHub (Jan 28, 2019): Looks like something with this server is weird. I tried this in the container: ``` $ wget https://registry.npmjs.org/rimraf --2019-01-28 17:30:09-- https://registry.npmjs.org/rimraf Resolving registry.npmjs.org (registry.npmjs.org)... 104.16.18.35, 104.16.17.35, 104.16.16.35, ... Connecting to registry.npmjs.org (registry.npmjs.org)|104.16.18.35|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 63374 (62K) [application/json] Saving to: ‘rimraf’ rimraf 71%[=============> ] 44.03K --.-KB/s in 0.005s 2019-01-28 17:30:09 (8.87 MB/s) - Read error at byte 45089/63374 (Error in the pull function.). Retrying. --2019-01-28 17:30:10-- (try: 2) https://registry.npmjs.org/rimraf Connecting to registry.npmjs.org (registry.npmjs.org)|104.16.18.35|:443... connected. HTTP request sent, awaiting response... 206 Partial Content Length: 63374 (62K), 18285 (18K) remaining [application/json] Saving to: ‘rimraf’ rimraf 100%[++++++++++++++=====>] 61.89K --.-KB/s in 0.003s 2019-01-28 17:30:10 (6.00 MB/s) - ‘rimraf’ saved [63374/63374] ``` Another try: ``` $ wget https://registry.npmjs.org/rimraf --2019-01-28 17:30:51-- https://registry.npmjs.org/rimraf Resolving registry.npmjs.org (registry.npmjs.org)... 104.16.19.35, 104.16.18.35, 104.16.17.35, ... Connecting to registry.npmjs.org (registry.npmjs.org)|104.16.19.35|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 63374 (62K) [application/json] Saving to: ‘rimraf.1’ rimraf.1 100%[===================>] 61.89K --.-KB/s in 0.02s 2019-01-28 17:30:51 (3.79 MB/s) - ‘rimraf.1’ saved [63374/63374] ``` Now I got the file on the first try, but the first time around not, see the `Read error`. wget then was smart enough to fetch the rest of the file (`http 206`, I diff'd the files and they're the same) but I don't know if npm is doing the same thing (since a `http 200` was sent). If not, that explains the weird behavior I believe.

kerem commented

2026-03-01 14:40:33 +03:00

Author

Owner

@pirate commented on GitHub (Jan 28, 2019):

Very interesting, it looks like you have some network issue that starts dropping response data after ~64kb. I've never seen anything like that.

What OS are you running on? Have you experienced anything like these truncated responses in your day-to-day (non-docker) activities?

Do you mind re-running that wget test with -v, or use curl -v? At this point, I'm just curious what could be causing this...

@pirate commented on GitHub (Jan 28, 2019): Very interesting, it looks like you have some network issue that starts dropping response data after ~64kb. I've never seen anything like that. What OS are you running on? Have you experienced anything like these truncated responses in your day-to-day (non-docker) activities? Do you mind re-running that wget test with `-v`, or use `curl -v`? At this point, I'm just curious what could be causing this...

kerem commented

2026-03-01 14:40:33 +03:00

Author

Owner

@mawmawmawm commented on GitHub (Jan 28, 2019):

Has never been an issue so far - docker is running on my Synology NAS DS716+ with their (linux based) DSM 6.2.1 software / OS.

Here we go:

pptruser@fa50a2cb874e:/data/dl-test$ wget -v https://registry.npmjs.org/rimraf                                                                                                  
--2019-01-28 22:00:25--  https://registry.npmjs.org/rimraf                                                                                                                      
Resolving registry.npmjs.org (registry.npmjs.org)... 104.16.17.35, 104.16.26.35, 104.16.22.35, ...                                                                              
Connecting to registry.npmjs.org (registry.npmjs.org)|104.16.17.35|:443... connected.                                                                                           
HTTP request sent, awaiting response... 200 OK                                                                                                                                  
Length: 63374 (62K) [application/json]                                                                                                                                          
Saving to: ‘rimraf’                                                                                                                                                             
                                                                                                                                                                                
rimraf              100%[===================>]  61.89K  --.-KB/s    in 0.02s                                                                                                    
                                                                                                                                                                                
2019-01-28 22:00:25 (3.16 MB/s) - ‘rimraf’ saved [63374/63374]

That worked as expected. I gave it more tries and after 13 successful ones, I saw the error / partial download again, however now on a different byte.

pptruser@fa50a2cb874e:/data/dl-test$ wget -v https://registry.npmjs.org/rimraf                                                                                                  
--2019-01-28 22:03:10--  https://registry.npmjs.org/rimraf                                                                                                                      
Resolving registry.npmjs.org (registry.npmjs.org)... 104.16.16.35, 104.16.20.35, 104.16.25.35, ...                                                                              
Connecting to registry.npmjs.org (registry.npmjs.org)|104.16.16.35|:443... connected.                                                                                           
HTTP request sent, awaiting response... 200 OK                                                                                                                                  
Length: 63374 (62K) [application/json]                                                                                                                                          
Saving to: ‘rimraf.14’                                                                                                                                                          
                                                                                                                                                                                
rimraf.14            72%[=============>      ]  44.71K  --.-KB/s    in 0.02s                                                                                                    
                                                                                                                                                                                
2019-01-28 22:03:11 (2.45 MB/s) - Read error at byte 45779/63374 (Error in the pull function.). Retrying.                                                                       
                                                                                                                                                                                
--2019-01-28 22:03:12--  (try: 2)  https://registry.npmjs.org/rimraf                                                                                                            
Connecting to registry.npmjs.org (registry.npmjs.org)|104.16.16.35|:443... connected.                                                                                           
HTTP request sent, awaiting response... 206 Partial Content                                                                                                                     
Length: 63374 (62K), 17595 (17K) remaining [application/json]                                                                                                                   
Saving to: ‘rimraf.14’                                                                                                                                                          
                                                                                                                                                                                
rimraf.14           100%[++++++++++++++=====>]  61.89K  --.-KB/s    in 0.003s                                                                                                   
                                                                                                                                                                                
2019-01-28 22:03:12 (5.27 MB/s) - ‘rimraf.14’ saved [63374/63374]

This time from a different server (104.16.16.35) however.

@mawmawmawm commented on GitHub (Jan 28, 2019): Has never been an issue so far - docker is running on my Synology NAS DS716+ with their (linux based) DSM 6.2.1 software / OS. Here we go: ``` pptruser@fa50a2cb874e:/data/dl-test$ wget -v https://registry.npmjs.org/rimraf --2019-01-28 22:00:25-- https://registry.npmjs.org/rimraf Resolving registry.npmjs.org (registry.npmjs.org)... 104.16.17.35, 104.16.26.35, 104.16.22.35, ... Connecting to registry.npmjs.org (registry.npmjs.org)|104.16.17.35|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 63374 (62K) [application/json] Saving to: ‘rimraf’ rimraf 100%[===================>] 61.89K --.-KB/s in 0.02s 2019-01-28 22:00:25 (3.16 MB/s) - ‘rimraf’ saved [63374/63374] ``` That worked as expected. I gave it more tries and after 13 successful ones, I saw the error / partial download again, however now on a different byte. ``` pptruser@fa50a2cb874e:/data/dl-test$ wget -v https://registry.npmjs.org/rimraf --2019-01-28 22:03:10-- https://registry.npmjs.org/rimraf Resolving registry.npmjs.org (registry.npmjs.org)... 104.16.16.35, 104.16.20.35, 104.16.25.35, ... Connecting to registry.npmjs.org (registry.npmjs.org)|104.16.16.35|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 63374 (62K) [application/json] Saving to: ‘rimraf.14’ rimraf.14 72%[=============> ] 44.71K --.-KB/s in 0.02s 2019-01-28 22:03:11 (2.45 MB/s) - Read error at byte 45779/63374 (Error in the pull function.). Retrying. --2019-01-28 22:03:12-- (try: 2) https://registry.npmjs.org/rimraf Connecting to registry.npmjs.org (registry.npmjs.org)|104.16.16.35|:443... connected. HTTP request sent, awaiting response... 206 Partial Content Length: 63374 (62K), 17595 (17K) remaining [application/json] Saving to: ‘rimraf.14’ rimraf.14 100%[++++++++++++++=====>] 61.89K --.-KB/s in 0.003s 2019-01-28 22:03:12 (5.27 MB/s) - ‘rimraf.14’ saved [63374/63374] ``` This time from a different server (`104.16.16.35`) however.

kerem commented

2026-03-01 14:40:33 +03:00

Author

Owner

@pirate commented on GitHub (Jan 29, 2019):

Can you try with curl passing -H "Accept-Encoding: gzip?

@pirate commented on GitHub (Jan 29, 2019): Can you try with curl passing `-H "Accept-Encoding: gzip`?

kerem commented

2026-03-01 14:40:33 +03:00

Author

Owner

@mawmawmawm commented on GitHub (Jan 30, 2019):

I tried

wget --header='Accept-Encoding: gzip' https://registry.npmjs.org/rimraf

instead - same thing, I just find the wget output a bit friendlier to read. I did this directly on my machine as well as on the NAS.

I tried it ~50 times and I saw that the content-length was different sometimes (see the values in [brackets], sometimes 10284, 10070, 10281 etc:

mweber@Reti2 ~> wget --header='Accept-Encoding: gzip' https://registry.npmjs.org/rimraf
--2019-01-29 22:22:37--  https://registry.npmjs.org/rimraf
Resolving registry.npmjs.org (registry.npmjs.org)... 104.16.22.35, 104.16.27.35, 104.16.21.35, ...
Connecting to registry.npmjs.org (registry.npmjs.org)|104.16.22.35|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [application/json]
Saving to: ‘rimraf.47’

rimraf.47                                                           [ <=>                                                                                                                                                   ]   9.83K  --.-KB/s    in 0s

2019-01-29 22:22:38 (20.7 MB/s) - ‘rimraf.47’ saved [10070]

mweber@Reti2 ~> wget --header='Accept-Encoding: gzip' https://registry.npmjs.org/rimraf
--2019-01-29 22:22:38--  https://registry.npmjs.org/rimraf
Resolving registry.npmjs.org (registry.npmjs.org)... 104.16.22.35, 104.16.27.35, 104.16.21.35, ...
Connecting to registry.npmjs.org (registry.npmjs.org)|104.16.22.35|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [application/json]
Saving to: ‘rimraf.48’

rimraf.48                                                           [ <=>                                                                                                                                                   ]  10.04K  --.-KB/s    in 0.002s

2019-01-29 22:22:38 (4.84 MB/s) - ‘rimraf.48’ saved [10281]

mweber@Reti2 ~> wget --header='Accept-Encoding: gzip' https://registry.npmjs.org/rimraf
--2019-01-29 22:22:38--  https://registry.npmjs.org/rimraf
Resolving registry.npmjs.org (registry.npmjs.org)... 104.16.22.35, 104.16.27.35, 104.16.21.35, ...
Connecting to registry.npmjs.org (registry.npmjs.org)|104.16.22.35|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [application/json]
Saving to: ‘rimraf.49’

rimraf.49                                                           [ <=>                                                                                                                                                   ]  10.04K  --.-KB/s    in 0.005s

2019-01-29 22:22:39 (2.04 MB/s) - ‘rimraf.49’ saved [10284]

mweber@Reti2 ~> wget --header='Accept-Encoding: gzip' https://registry.npmjs.org/rimraf
--2019-01-29 22:22:39--  https://registry.npmjs.org/rimraf
Resolving registry.npmjs.org (registry.npmjs.org)... 104.16.22.35, 104.16.27.35, 104.16.21.35, ...
Connecting to registry.npmjs.org (registry.npmjs.org)|104.16.22.35|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [application/json]
Saving to: ‘rimraf.50’

rimraf.50                                                           [ <=>                                                                                                                                                   ]  10.04K  --.-KB/s    in 0.005s

2019-01-29 22:22:39 (2.17 MB/s) - ‘rimraf.50’ saved [10284]

I renamed those files to .zip, extracted and diff'd them and they were the same afterwards. This is a mystery to me :)

@mawmawmawm commented on GitHub (Jan 30, 2019): I tried ``` wget --header='Accept-Encoding: gzip' https://registry.npmjs.org/rimraf ``` instead - same thing, I just find the `wget` output a bit friendlier to read. I did this directly on my machine as well as on the NAS. I tried it ~50 times and I saw that the content-length was different sometimes (see the values in [brackets], sometimes 10284, 10070, 10281 etc: ``` mweber@Reti2 ~> wget --header='Accept-Encoding: gzip' https://registry.npmjs.org/rimraf --2019-01-29 22:22:37-- https://registry.npmjs.org/rimraf Resolving registry.npmjs.org (registry.npmjs.org)... 104.16.22.35, 104.16.27.35, 104.16.21.35, ... Connecting to registry.npmjs.org (registry.npmjs.org)|104.16.22.35|:443... connected. HTTP request sent, awaiting response... 200 OK Length: unspecified [application/json] Saving to: ‘rimraf.47’ rimraf.47 [ <=> ] 9.83K --.-KB/s in 0s 2019-01-29 22:22:38 (20.7 MB/s) - ‘rimraf.47’ saved [10070] mweber@Reti2 ~> wget --header='Accept-Encoding: gzip' https://registry.npmjs.org/rimraf --2019-01-29 22:22:38-- https://registry.npmjs.org/rimraf Resolving registry.npmjs.org (registry.npmjs.org)... 104.16.22.35, 104.16.27.35, 104.16.21.35, ... Connecting to registry.npmjs.org (registry.npmjs.org)|104.16.22.35|:443... connected. HTTP request sent, awaiting response... 200 OK Length: unspecified [application/json] Saving to: ‘rimraf.48’ rimraf.48 [ <=> ] 10.04K --.-KB/s in 0.002s 2019-01-29 22:22:38 (4.84 MB/s) - ‘rimraf.48’ saved [10281] mweber@Reti2 ~> wget --header='Accept-Encoding: gzip' https://registry.npmjs.org/rimraf --2019-01-29 22:22:38-- https://registry.npmjs.org/rimraf Resolving registry.npmjs.org (registry.npmjs.org)... 104.16.22.35, 104.16.27.35, 104.16.21.35, ... Connecting to registry.npmjs.org (registry.npmjs.org)|104.16.22.35|:443... connected. HTTP request sent, awaiting response... 200 OK Length: unspecified [application/json] Saving to: ‘rimraf.49’ rimraf.49 [ <=> ] 10.04K --.-KB/s in 0.005s 2019-01-29 22:22:39 (2.04 MB/s) - ‘rimraf.49’ saved [10284] mweber@Reti2 ~> wget --header='Accept-Encoding: gzip' https://registry.npmjs.org/rimraf --2019-01-29 22:22:39-- https://registry.npmjs.org/rimraf Resolving registry.npmjs.org (registry.npmjs.org)... 104.16.22.35, 104.16.27.35, 104.16.21.35, ... Connecting to registry.npmjs.org (registry.npmjs.org)|104.16.22.35|:443... connected. HTTP request sent, awaiting response... 200 OK Length: unspecified [application/json] Saving to: ‘rimraf.50’ rimraf.50 [ <=> ] 10.04K --.-KB/s in 0.005s 2019-01-29 22:22:39 (2.17 MB/s) - ‘rimraf.50’ saved [10284] ``` I renamed those files to `.zip`, extracted and diff'd them and they were the same afterwards. This is a mystery to me :)

kerem commented

2026-03-01 14:40:33 +03:00

Author

Owner

@pirate commented on GitHub (Feb 4, 2019):

I'm going to close this since it seems to be specific to your machine and unlikely to affect other people. I'm still very much interested in figuring it out though. You could try Wiresharking the traffic from the container to see if there's any ICMP or TCP weirdness that's ending the stream early.

@pirate commented on GitHub (Feb 4, 2019): I'm going to close this since it seems to be specific to your machine and unlikely to affect other people. I'm still very much interested in figuring it out though. You could try Wiresharking the traffic from the container to see if there's any ICMP or TCP weirdness that's ending the stream early.

kerem referenced this issue

2026-03-01 17:51:50 +03:00

[GH-ISSUE #90] Apple News articles = 404 #1573

kerem referenced this issue

2026-03-14 20:56:17 +03:00

[GH-ISSUE #90] Apple News articles = 404 #3081

Rows
Columns

[GH-ISSUE #134] Intermittent network response dropping when building and executing inside docker #90