"TypeError: Cannot close a CLOSED writable stream" thrown after reading data from zip entry

[akesling]

If there is a better place to report this issue, let me know.

Witnessed behavior

Often, when I read the content of files from a zip archive, zip.js throws an uncaught "TypeError: Cannot close a CLOSED writable stream" exception. I first noticed this with "pause on uncaught exceptions" set in the Chrome debugger.

This is also reproducible on https://gildas-lormeau.github.io/zip-manager/ when I load a zip archive and try to extract a file from it.

Browser: Chrome version 122.0.6261.94 on MacOS

Attached is an archive for which I have seen this behavior in https://gildas-lormeau.github.io/zip-manager/ . I created this archive with zip -r archive.zip archive/ on MacOS. See zip --version if relevant.

Reproduction steps

1. Load https://gildas-lormeau.github.io/zip-manager/
2. Open Chrome dev tools to the "sources" tab, and click the "pause on uncaught exceptions" checkbox under the "breakpoints" accordion. Leave the dev tools open to catch the exception.
3. Click "Import zip" and load archive.zip
4. Double-click archive folder
5. Double-click foo.txt and follow steps to download
6. Witness Chrome dev tools catch an "TypeError: Cannot close a CLOSED writable stream" exception on an await a.getWriter().close() call

[gildas-lormeau]

Thank you for the detailed report, I was able to reproduce and fix the issue. The fix is available in the version 2.7.37 I've just published on NPM and JSR.

[akesling]

Thank you for the quick reply.

Have you updated https://gildas-lormeau.github.io/zip-manager/ to use 2.7.37? Using 2.7.37 in my project does not fix the error and I'm still seeing it on https://gildas-lormeau.github.io/zip-manager/ per the reproduction steps.

[gildas-lormeau]

it should indeed be fixed in the demo. Did you refresh the page to make sure the service worker is updated? On my end, I do not see any uncaught exception anymore when trying to reproduce the issue.

[akesling]

Things look good today! You're probably right... something could easily have been cached out of sight somewhere even with no-cache on in the dev tools.

Thank you.

[gildas-lormeau]

Actually, the service worker is always updated after a refresh. This is how I decided to implement transparent updates in the demo.

[akesling]

Maybe there was an HTTP proxy cache somewhere still handing me the old zip-manager? 🤷

I'm less sure as to why my local build had the issue yesterday and worked today though.... Hopefully there's nothing flakey lurking in the shadows.

[gildas-lormeau]

FYI, I removed the try/catch surrounding the Writer#close() calls in the last version as it didn't work as intended (the exception was not caught). Hopefully, this will make the error more visible if it's still present.