Closed DebianArch64 closed 5 months ago
Did you implement anything to ensure that websocket messages are ordered or does your environment guarantee it? See https://stackoverflow.com/questions/11804721/can-websocket-messages-arrive-out-of-order
Did you implement anything to ensure that websocket messages are ordered or does your environment guarantee it? See https://stackoverflow.com/questions/11804721/can-websocket-messages-arrive-out-of-order
The websocket isn't an issue, it's receiving the same amount of bytes and in the right order (I printed out size of bytes received in my erlang backend and size of bytes written from JavaScript) so the zip I'm making using .add function is what's wonky, it's really a few of the exact same entries that aren't writing correctly (the failed to inflate message for the same files each time)
Can you reproduce the issue if you replace new WritableStream({ ... })
with a writable
property from a TransformStream
object? In that case, is the readable
property of the TransformStream
returning a corrupted stream?
Same thing happens
const {readable, writable} = new TransformStream({flush: () => { writer.close() }})
const reader = readable.getReader()
const yes = async () => {
while (true) {
const { done, value } = await reader.read();
if (done) {
break;
}
// send chunk
}
yes()
writer.readable.pipeTo(writable, { preventClose: true })
Output without delay:
Archive: /Users/debianarch/Downloads/install (18).ipa
inflating: Payload/Taurine.app/essential_0-4_iphoneos-arm.deb
inflating: Payload/Taurine.app/bootstrap.tar.gz
error: invalid compressed data to inflate
file #3: bad zipfile offset (local header sig): 12594496
file #4: bad zipfile offset (local header sig): 12603319
file #5: bad zipfile offset (local header sig): 12617048
file #6: bad zipfile offset (local header sig): 15534336
file #7: bad zipfile offset (local header sig): 15535204
file #8: bad zipfile offset (local header sig): 15535920
file #9: bad zipfile offset (local header sig): 15536177
file #10: bad zipfile offset (local header sig): 15776964
file #11: bad zipfile offset (local header sig): 15777490
file #12: bad zipfile offset (local header sig): 15779564
file #13: bad zipfile offset (local header sig): 15780306
file #14: bad zipfile offset (local header sig): 15797892
file #15: bad zipfile offset (local header sig): 15799206
file #16: bad zipfile offset (local header sig): 15799489
file #17: bad zipfile offset (local header sig): 28942874
file #18: bad zipfile offset (local header sig): 28961940
file #19: bad zipfile offset (local header sig): 28968084
inflating: Payload/Taurine.app/signcert.p12
inflating: Payload/Taurine.app/Info.plist
inflating: Payload/Taurine.app/PkgInfo
inflating: Payload/Taurine.app/_CodeSignature/CodeResources
inflating: Payload/Taurine.app/Taurine
My bad found the issue, i'm embarrassed sorry for wasting your time
No problem, I'm glad to hear that the issue is fixed :)
Probably something on my end, but for some reason Zip files are more corrupt when having no delay between adding files. So, there are two issues but hoping to have them both fixed on my side
The Output Output without delay:
Output with delay:
The Code Pretty much, I have an emscripten WASM directory that I'm zipping up using zip.js. To be speedy I am uploading the chunks to a websocket as it's being zipped up: