i think launching puppeteer too early can block the async event loop. try to init streaming first then start puppeteer. that solved it for me on a similar project.
Based on my observations, the behavior you’re experiencing is due to how resource allocation affects the asynchronous event loop. When Puppeteer is launched first, its initialization likely occupies key resources that are later needed for establishing streaming callbacks. In my own testing, I found that setting up file streaming before invoking Puppeteer made the callback events fire as expected. Adjusting the sequence of operations or ensuring that both processes utilize separate resources can help alleviate the issue. This reordering approach has consistently resolved similar problems in my projects.
Based on my own experience, launching Puppeteer early appears to engage significant system resources that interfere with subsequent asynchronous operations like file streaming callbacks. I encountered a similar behavior when I incorporated a heavy visualization library; callbacks delayed until the library initialized completely. I resolved it by restructuring my code flow to trigger file stream setups and event listeners before invoking any resource-intensive functions. This approach allowed the asynchronous mechanisms to initialize properly, after which Puppeteer could operate without affecting the communication between event callbacks.
hey, i had a similar issue. running puppeteer early caused delays in callbacks due to resource hogging. initializing file streaming before puppeteer fixed it for me, so try swapping their order to avoid event blocking. good luck!