Download project from editor not working

[quinton-ashley]

p5.js version

any

What is your operating system?

Mac OS

Web browser and version

No response

Actual Behavior

Project not being downloaded.

Expected Behavior

Project downloads as zip file.

Steps to reproduce

I want to be able to click download and download this project:
https://editor.p5js.org/.Fragmented_HF_ang./sketches/qbiGrxyps

[adithyaa-s]

Hi, is this issue open for the community

[raclim]

@adithyaa-s please feel free to take a look into this issue!

[Nixxx19]

Hi @raclim, I’ve opened PR #3770 with the proposed fix. It appears this issue is a duplicate of #3746.
Whenever it’s convenient, I’d really appreciate a review. Thanks!

[adithyaa-s]

Hey @raclim ,

Currently I've implemented

• Sending response headers immediately before the ZIP is generated
• Using streaming instead of buffering the entire file in memory
• Adding proper error handling and a 30-second timeout on S3 requests

Just changed the project.controller.js file

recording_2026-01-29_20.00.50.mp4

If there's something else that I should work on, or if I am missing something, please let me know if I should change anything or raise a PR.

[adithyaa-s]

Should I raise the PR @quinton-ashley @raclim

[raclim]

Sorry for the delay @adithyaa-s and thank you for digging into this!

Would you mind taking a look if the earlier PR (#3770) overlaps with your solution and share your thoughts? If it doesn't address it in the same way, please feel free to go ahead and raise the PR!

[raclim]

I'm sorry for jumping on the response earlier without fleshing it out in more detail—I ended up merging in the current PR we have for now since it might help alleviate things in the short term.

It seems like the issue is mainly impacting sketches with a large amount of assets, since larger projects take a longer time to build the ZIP so the gateway times out, while smaller projects seem to be okay.

After taking a closer look, I think the proposed changes here and in the PR make progress towards the issue and is an overall improvement for error handling. However, I'm not sure if it'll hold consistently, especially for much larger projects, and we probably want to work towards a longer term fix. I think it could potentially look like streaming the ZIP as it's created before building it all first, generate the ZIP in the background, or even potentially adding limits to the number of assets a sketch should have (which is probably a separate issue), that I think @Jatin24062005 raised within the PR.

[Nixxx19]

Hi @raclim,

Since you mentioned looking for a more robust long-term solution to handle larger projects without hitting gateway timeouts, I’d love to take a crack at that and work on this issue!

Proposed Approach:

I plan to refactor the download logic to use JSZip.generateNodeStream(). This will allow the server to:

• Avoid Timeouts: Start sending response headers and streaming data immediately as the ZIP is being built, preventing Cloudflare from timing out while waiting for a buffered response.
• Reduce Memory Overhead: Stream the data directly to the client instead of buffering the entire archive in the Node.js process memory.
• Maintain Performance: This addresses the bottlenecks of asset fetching and ZIP generation without requiring a full background-job architecture.

Does this align with the direction you're thinking, or would you prefer I explore the background job approach?

[raclim]

@Nixxx19 I think using JSZip.generateNodeStream() could be a good next step! I think we might still want to be careful to not fetch everything upfront before responding to avoid running into the same issue. If JSZip still buffers to much, we can probably explore the background job afterwards? Also open to other thoughts as well on this!

[Nixxx19]

Thanks @raclim! That makes total sense. I’ll look into piping the S3 fetch streams directly into the JSZip instance to ensure we don't fetch everything upfront.

By avoiding await Promise.all() and processing the assets sequentially (or in small chunks), the stream should start flowing immediately. This will trigger the first byte of the response as soon as possible, keeping the connection alive and preventing the gateway timeout.

If we find that JSZip's memory footprint is still too high for massive sketches, we can definitely pivot to the background job approach as a follow-up. I'll start working on the PR for the streaming implementation!